Chris, a short(er) answer to your addition below.
I did not at first share your perception but maybe do now. If the argument
was that ELSE and other constructs like FINALLY or CATCH are horrible
because they follow other code and important things should be first, that is
a silly argument. Many
Cameron,
Your suggestion makes me shudder!
Removing all earlier lines of code is often guaranteed to generate errors as
variables you are using are not declared or initiated, modules are not
imported and so on.
Removing just the line or three where the previous error happened would also
have a
On Mon, 10 Oct 2022 at 14:59, wrote:
>
> >>>Which is more disparaging: "I couldn't find anyone suggesting this" or
> "The only place I could find it was a PHP style guide"?
> >>>ChrisA
>
> Chris,
>
> If someone says they heard something from their own personal guru, people
> often do not feel
>>>Which is more disparaging: "I couldn't find anyone suggesting this" or
"The only place I could find it was a PHP style guide"?
>>>ChrisA
Chris,
If someone says they heard something from their own personal guru, people
often do not feel threatened or argue. I often am told nutrition or medical
I won't reply to everything Dave says and especially not the parts I fully
agree with.
I think in many situations in life there is no ONE way to do things so most
advice is heuristic at best and many exceptions may exist depending on your
chosen approach. As such, I do not really think in
[This is an answer for Peter and can easily be skipped by those who know or
have no wish to.]
Strictly speaking Peter, the word "pipe" may not mean quite something in
Python but other concepts like chaining may be better.
The original use of the word I am used to was at the UNIX shell level
On Mon, 10 Oct 2022 at 11:52, MRAB wrote:
>
> On 2022-10-10 00:40, dn wrote:
> > On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
> > wrote:
> >
> >> "shortest block first"
> >
> > Have never heard this advice before. Kind-of rankled with me, as it did
> > for others.
> >
> > Enquiring minds
On 10/10/2022 13.47, MRAB wrote:
On 2022-10-10 00:40, dn wrote:
On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
wrote:
"shortest block first"
Have never heard this advice before. Kind-of rankled with me, as it did
for others.
Enquiring minds want to know... Played Duck, duck, go on
On 10/9/2022 1:29 PM, Peter J. Holzer wrote:
> On 2022-10-09 12:59:09 -0400, Thomas Passin wrote:
>>
https://stackoverflow.com/questions/4284313/how-can-i-check-the-syntax-of-python-script-without-executing-it
>>
>> People seemed especially enthusiastic about the one-liner from jmd_dk.
>
> I
On 2022-10-10 00:40, dn wrote:
On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
wrote:
"shortest block first"
Have never heard this advice before. Kind-of rankled with me, as it did
for others.
Enquiring minds want to know... Played Duck, duck, go on this: zero hits
amongst a pile of
On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
wrote:
"shortest block first"
Have never heard this advice before. Kind-of rankled with me, as it did
for others.
Enquiring minds want to know... Played Duck, duck, go on this: zero hits
amongst a pile of similar phrases - turns-out
On 09Oct2022 21:46, Antoon Pardon wrote:
Is it that onerous to fix one thing and run it again? It was once when
you
handed in punch cards and waited a day or on very busy machines.
Yes I find it onerous, especially since I have a pipeline with unit tests
and other tools that all have to redo
On Mon, 10 Oct 2022 at 06:50, Antoon Pardon wrote:
> I just want a parser that doesn't give up on encoutering the first syntax
> error. Maybe do some semantic checking like checking the number of parameters.
That doesn't make sense though. It's one thing to keep going after
finding a
Am Sun, Oct 09, 2022 at 07:51:12PM +0200 schrieb Antoon Pardon:
> >But the point is: you can't (there is no way to) be sure the
> >9+ errors really are errors.
> >
> >Unless you further constrict what sorts of errors you are
> >looking for and what margin of error or leeway for false
> >positives
> On 9 Oct 2022, at 18:54, Antoon Pardon wrote:
>
>
>
> Op 9/10/2022 om 19:23 schreef Karsten Hilbert:
>> Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:
>>
>>> Op 9/10/2022 om 17:49 schreef Avi Gross:
My guess is that finding 100 errors might turn out to be
Op 9/10/2022 om 21:44 schreef Avi Gross:
But an error like setting the size of a fixed length data structure to the
right size may result in oodles of errors about being out of range that
magically get fixed by one change. Sometimes too much info just gives you a
headache.
So? The user of
On 2022-10-09 15:32:13 -0400, Avi Gross wrote:
> and of course no pipelines.
Since you've now used that term repeatedly: What is a pipeline in
Python?
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |
On 2022-10-09 15:18:19 -0400, Avi Gross wrote:
> Antoon, it may also relate to an interpreter versus compiler issue.
>
> Something like a compiler for C does not do anything except write code in
> an assembly language. It can choose to keep going after an error and start
> looking some more from
Op 9/10/2022 om 21:18 schreef Avi Gross:
Antoon, it may also relate to an interpreter versus compiler issue.
Something like a compiler for C does not do anything except write code in
an assembly language. It can choose to keep going after an error and start
looking some more from a less
Op 9/10/2022 om 21:18 schreef Avi Gross:
Antoon, it may also relate to an interpreter versus compiler issue.
Something like a compiler for C does not do anything except write code in
an assembly language. It can choose to keep going after an error and start
looking some more from a less
I will say that those of us meaning me, who express reservations are not
arguing it is a bad idea to get more info in one sweep. Many errors come in
bunches.
If I keep calling some function with the wrong number or type of arguments,
it may be the same in a dozen places in my code. The first
Peter,
There can be excellent reasons to undo a pipeline like I described. I often
write it carefully in smaller chunks while debugging and make it more
elegant later ...
But someone amused me by explaining they were going to let people believe
the code was written by them so it had to fit their
Antoon, it may also relate to an interpreter versus compiler issue.
Something like a compiler for C does not do anything except write code in
an assembly language. It can choose to keep going after an error and start
looking some more from a less stable place.
Interpreters for Python have to
Sorry, I forgot to mention that I'm using Windows 10 64-bit.
From: jsch...@sbcglobal.net
Sent: Sunday, October 9, 2022 1:48 PM
To: 'python-list@python.org'
Subject: AWS upload script written in python - verify number of processes
used
I have an AWS upload script to upload to my S3
Fair enough, Chris. There may be some overlap with the size of code for the
most common cases but sometimes the opposite as those may be more complex
to deal with.
A reality for many programmers today is to not micromanage too early as
things are often fast enough and any tweaking is best done
On 2022-10-09 18:51, Antoon Pardon wrote:
Op 9/10/2022 om 19:23 schreef Karsten Hilbert:
Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:
Op 9/10/2022 om 17:49 schreef Avi Gross:
My guess is that finding 100 errors might turn out to be misleading. If you
fix just the first,
I have an AWS upload script to upload to my S3 bucket and I have it
configured to use 6 processes. How can I verify that it's using 6 processes
to do the upload?
I have wireshark installed, but I'm not very familiar with it. I also have
tried tasklist, but that doesn't tell me what I want to
PyCharm.
Does a good job of separating these are really errors from do you really mean
that warnings from this word is spelled right.
https://www.jetbrains.com/pycharm/
From: Python-list on
behalf of Antoon Pardon
Date: Sunday, October 9, 2022 at 6:11 AM
To: python-list@python.org
Subject:
Op 9/10/2022 om 19:23 schreef Karsten Hilbert:
Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:
Op 9/10/2022 om 17:49 schreef Avi Gross:
My guess is that finding 100 errors might turn out to be misleading. If you
fix just the first, many others would go away.
At this moment
On 2022-10-09 19:23:41 +0200, Karsten Hilbert wrote:
> Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:
> > Op 9/10/2022 om 17:49 schreef Avi Gross:
> > >My guess is that finding 100 errors might turn out to be misleading. If you
> > >fix just the first, many others would go away.
>
On 2022-10-09 12:59:09 -0400, Thomas Passin wrote:
> https://stackoverflow.com/questions/4284313/how-can-i-check-the-syntax-of-python-script-without-executing-it
>
> People seemed especially enthusiastic about the one-liner from jmd_dk.
I don't think that one-liner solves Antoon's requirement of
Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:
> Op 9/10/2022 om 17:49 schreef Avi Gross:
> >My guess is that finding 100 errors might turn out to be misleading. If you
> >fix just the first, many others would go away.
>
> At this moment I would prefer a tool that reported 100
https://stackoverflow.com/questions/4284313/how-can-i-check-the-syntax-of-python-script-without-executing-it
People seemed especially enthusiastic about the one-liner from jmd_dk.
On 10/9/2022 12:17 PM, Peter J. Holzer wrote:
On 2022-10-09 12:09:17 +0200, Antoon Pardon wrote:
I would like a
On 2022-10-09 12:34:22 -0400, Avi Gross wrote:
> I have seen programmers who have taken an elegant pipeline I have built
> apart and made it into many lines of code reassignment the value of each
> step to the same or different variables and other ways of lengthening or
> obscuring my intent.
I
Op 9/10/2022 om 17:49 schreef Avi Gross:
My guess is that finding 100 errors might turn out to be misleading. If you
fix just the first, many others would go away.
At this moment I would prefer a tool that reported 100 errors, which would
allow me to easily correct 10 real errors, over the
On 2022-10-09 12:18:09 -0400, Avi Gross wrote:
> Smallest code blocks first may be a more modern invention.
>
> Some would argue for a rule related to efficiency of execution. When you
> have multiple blocks as in an if-else or case statement with multiple
> choices, that you order the most
Since many languages allow placing multiple statements on one line or
spreading one over many lines, it seems that the number of lines in code
can be adjusted.
If I have a line like:
Alpha, beta, gamma, delta = 1, 2, 3, 4
Could that be rewritten as 4 or more lines?
Surely! Especially if
On Mon, 10 Oct 2022 at 03:46, Avi Gross wrote:
>
> Chris, I was not arguing that at all.
Maybe not intentionally, but you did lend a lot of weight to that argument :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Chris, I was not arguing that at all.
I was saying some rationales about how to order choices exist based on
ideas like efficiency or other considerations. Sometimes people are
mistaken as something may take constant time as implemented. And yes, many
rules have countless exceptions. For
Since many languages allow placing multiple statements on one line or
spreading one over many lines, it seems that the number of lines in code
can be adjusted.
If I have a line like:
Alpha, beta, gamma, delta = 1, 2, 3, 4
Could that be rewritten as 4 or more lines?
I have seen programmers who
On Mon, 10 Oct 2022 at 03:22, Avi Gross wrote:
>
> Smallest code blocks first may be a more modern invention.
>
> Some would argue for a rule related to efficiency of execution. When you
> have multiple blocks as in an if-else or case statement with multiple
> choices, that you order the most
Am Sun, Oct 09, 2022 at 05:37:59AM +0100 schrieb Axy via Python-list:
> Python is awesome because it's semantic is clear for the majority, but there
> are places
> that look odd. In case of "for", "else" looks logically tied with "for"
> clause, but
> actually it is not. It's tied with "break"
Smallest code blocks first may be a more modern invention.
Some would argue for a rule related to efficiency of execution. When you
have multiple blocks as in an if-else or case statement with multiple
choices, that you order the most common cases first. Those shorten
execution more often than
On 2022-10-09 12:09:17 +0200, Antoon Pardon wrote:
> I would like a tool that tries to find as many syntax errors as possible in
> a python file. I know there is the risk of false positives when a tool tries
> to recover from a syntax error and proceeds but I would prefer that over the
> current
Anton
There likely are such programs out there but are there universal agreements
on how to figure out when a new safe zone of code starts where error
testing can begin?
For example a file full of function definitions might find an error in
function 1 and try to find the end of that function and
>Well, the value is productivity. No need to save puzzles "what this
>hanging else belongs to?"
if you get to the point where it's hard to tell which else lines up with
which if or for statement, I would suggest breaking things out into
well-named helper functions rather than worrying over
I would like a tool that tries to find as many syntax errors as possible
in a python file. I know there is the risk of false positives when a
tool tries to recover from a syntax error and proceeds but I would
prefer that over the current python strategy of quiting after the first
syntax error.
On 2022-10-09 05:37:59 +0100, Axy via Python-list wrote:
> Actually the reason I never used "else" was the violation of the rule
> of beauty "shortest block first".
That's a weird rule.
I can see justifications for "most common case first" and "most special
case first", but ordering the cases in
Yes, I'm aware that code readability becomes irrelevant for
short-duration projects. Beside the point. I'm wondering how important
it really is to have the shortest block first.
I also might be wrong in terminology, anyway, there are many rules that
make programmer's life easier, described
49 matches
Mail list logo
