RE: for -- else: what was the motivation?

[avi.e.gross]

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 are at the end precisely because they are not the
main code but have a role to play in making sure various conditions are
dealt with. What some of us ended up discussing was whether the advice made
much sense in a broader context and were reasonable to strive for. Many of
us say not as important as many other things, or not important at all.

I note some people looked at the way C had a FOR loop with three parts
between semicolons up front as syntactic sugar. No doubt clauses like ELSE
could in some way be moved around but the result may well violate other
sensibilities as that did because it is a rather nonstandard syntax.

I have seen languages with CASE or SWITCH statements that fall through and
allow some code to be written once and executed for several scenarios.
Others loathe the idea and want each case self-contained. There is no one
answer everyone likes. Languages are huge experiments for differing ideas.

But it is largely IRRELEVANT in that Python already made the decision and
for now it is what it is. We had a different argument a while back as to how
the word  ELSE captured what is happening linguistically and for many here
IT DOES NOT. But once you KNOW what it does, and you choose to use it, then
it works just as well as any other words because it is what it is. If having
an ELSE late disqualifies Python for this person, use another language! Of
course, PHP may not be ideal for so many other reasons!

 


-Original Message-
From: Python-list  On
Behalf Of Chris Angelico
Sent: Monday, October 10, 2022 12:21 AM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?

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 threatened or argue. I often am told 
> nutrition or medical or other advice that I simply ignore especially 
> if it is about exotic herbs to use or weird ideas like homeopathy or 
> that I should use language X because it is the only way to a haven or
heaven or whatever.
>
> What we had here was someone suggesting their advice was WELL-KNOWN 
> followed by lots of people sputtering about not having heard of it. I 
> actually think the advice would be reasonable in many circumstances as 
> long as it did not conflict with dozens of goals I find more 
> compelling but which vary on a case by case basis such as whether I am 
> prototyping something I will use once, ...

It's clearly not all that well known (none of us have heard of it, and it's
not exactly prominent on the internet), and it seems that most of us
disagree that it's even good advice. So, it's not really a good argument
against for-else.

> I have studied PHP but have never felt a need to use it and arguably 
> the roles it has played are often done commonly by other programs or
methods.

That's because PHP is terrible.

> So in my view, the objection is not about PHP but about uniqueness. If 
> the author of one Python textbook and no others, suggest that your 
> code should declare all imports in alphabetical order then declare all 
> functions in alphabetical order, they can not only safely be ignored, 
> but perhaps not taken seriously as imports sometimes need to be done 
> carefully if something needs something else and if a language needs 
> functions to be defined before another function body calls them, ...

It's not JUST about uniqueness. It's also that nobody but PHP programmers
seem to care about it. That's on par with going to an art supplies forum and
trying to argue that you should lay out your paints in a specific order,
because some kindergarten teacher always does it that way for the kids'
fingerpainting sessions.

No, actually, that's unfair to fingerpainting kindergarteners.

> But some people seem to miss a point we have discussed. The odd 
> clauses like ELSE after a loop (and quite a few variants in similar 
> and different cases) often provide guarantees such as making sure a file
opened is closed.

Citation needed.

> Are these things out of the way? Yes, but so what? I see things as a 
> whole not as just a single screen shot. If a loop has several optional 
> clauses lie we are discussing and you know they are normally near the 
> end, then look for them where they are.

So what's your point?

> I know some languages, JavaScript being an example, may have things 
> you might consider odd such as promoting some things like function 
> definitions found further in your code to near the top so you can use 
> a function that is 

RE: What to use for finding as many syntax errors as possible.

[avi.e.gross]

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 good chance of invalidating something.

Someone who really wants to be able to isolate large parts of their code so
that an error in once does not compromise lots of remaining code, might
build their code in small units on the level of single functions per file
and do lots of imports. They can then ask for all the files to be
pseudo-compiled to byte-code and that might provide lots of errors to look
at in one pass.

But asking for a one-file version to find errors and somehow go past them
and look for more is more daunting but of course can be done with partial
accuracy and usefulness at best.

As an analogy, if tolerated, think of a spell-checker on a document that can
find oodles of words spelled wrong. Unfortunately, a spell corrector can
drive us nuts if it knows little about context. If it sees a word like
"reid" should it just change it to "read" or "red" or perhaps "reed" or look
to see if the real problem is it is supposed to be unified (no space) with a
word before or after? Will it know if the word appears in a context where a
language like Latin or French or German or Hungarian is being quoted and
perhaps it is spelled right, or if wrong, has other more likely corrections?

Now if you add a grammar detector, and it knows you are looking for an
adjective or a verb or a noun, it may do better.

I use Google translate quite  a bit as a tool as I often have to type in
various languages and it provides a handy keyboard or lets me check if I
used the right grammar especially in languages with silly ideas that objects
can have 2 or even three genders. So putting in phrases like "this xyz" can
result in language-specific text that tells me if it is masculine or
feminine or perhaps neuter. But the reason I mention it is how often it is
WRONG. I mean many languages have multiple words that are spelled the same
but used and pronounced differently in various contexts. The English word
"read" can sound like reed or like red so past tense sounds different as in
I read that book last week versus please read it to me now. But some
languages such as Hebrew which generally may not show the vowels, can get
totally confused in this program as humans often need lots of context to
figure out whether the current short word is in a context where it means
"you: feminine and singular and is pronounced aht or it is a way of showing
what follows is a direct object and loosely means "the" in a redundant way
and is pronounced as "eht". Quite a few words have three or more possible
ways to pronounce the same letters and without vowel guides need context and
sometimes some spreadsheet-like ingenuity as multiple other words are also
in limbo and once resolved can impact what other words may now mean.
Obviously adding back the vowels makes things clear so people who are used
to seeing books written that old way can get hopelessly lost reading a
modern newspaper.

End of digression, just assume I could have gone on for many pages
describing my annoyances at what Google translate does to many other
languages that show the imperfections in what is really a great and powerful
tool.

Well parsing any program in most languages can be equally complex and
require lots of context. For example, you can often use the same identifier
to be the name of a regular variable or the name of a function and sometimes
other things such as the name of a module. They can often be disambiguated
in context. Perhaps the same name following by parentheses should be a
function call while a name followed by :: or ::: might in that language
require it to be the name of a module/package. If followed by [ it might
need to be something indexable such as an array or list and so on. So say
there is an error in the variable. Can the interpreter or linter figure out
what the error is and almost repair it? Can it see a variable name like
"alpXha" and note there is no such identifier in the current namespace but
there is one called "alpha" that might be the one without the X? But what if
what is missing is an open parent or maybe the matching close paren. Does it
know if the problem is a bad variable name or a bad function invocation or
one of many other possible problems. Code with a random blemish is often not
easily figured out. If I type the name of a function without parentheses, it
could be an attempt to call the function with no arguments (an error though
in many languages) or it could be I want to pass the function itself as n
argument in functional programming. But if I have another variable of type
array, might it not be parentheses missing but square brackets? 

The compiler or interpreter often cannot fix it so it often tries to skip
forward till it finds 

Re: for -- else: what was the motivation?

[Chris Angelico]

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 threatened or argue. I often am told nutrition or medical
> or other advice that I simply ignore especially if it is about exotic herbs
> to use or weird ideas like homeopathy or that I should use language X
> because it is the only way to a haven or heaven or whatever.
>
> What we had here was someone suggesting their advice was WELL-KNOWN followed
> by lots of people sputtering about not having heard of it. I actually think
> the advice would be reasonable in many circumstances as long as it did not
> conflict with dozens of goals I find more compelling but which vary on a
> case by case basis such as whether I am prototyping something I will use
> once, ...

It's clearly not all that well known (none of us have heard of it, and
it's not exactly prominent on the internet), and it seems that most of
us disagree that it's even good advice. So, it's not really a good
argument against for-else.

> I have studied PHP but have never felt a need to use it and arguably the
> roles it has played are often done commonly by other programs or methods.

That's because PHP is terrible.

> So in my view, the objection is not about PHP but about uniqueness. If the
> author of one Python textbook and no others, suggest that your code should
> declare all imports in alphabetical order then declare all functions in
> alphabetical order, they can not only safely be ignored, but perhaps not
> taken seriously as imports sometimes need to be done carefully if something
> needs something else and if a language needs functions to be defined before
> another function body calls them, ...

It's not JUST about uniqueness. It's also that nobody but PHP
programmers seem to care about it. That's on par with going to an art
supplies forum and trying to argue that you should lay out your paints
in a specific order, because some kindergarten teacher always does it
that way for the kids' fingerpainting sessions.

No, actually, that's unfair to fingerpainting kindergarteners.

> But some people seem to miss a point we have discussed. The odd clauses like
> ELSE after a loop (and quite a few variants in similar and different cases)
> often provide guarantees such as making sure a file opened is closed.

Citation needed.

> Are these things out of the way? Yes, but so what? I see things as a whole
> not as just a single screen shot. If a loop has several optional clauses lie
> we are discussing and you know they are normally near the end, then look for
> them where they are.

So what's your point?

> I know some languages, JavaScript being an example, may have things you
> might consider odd such as promoting some things like function definitions
> found further in your code to near the top so you can use a function that is
> not defined till later even without something like a forward declaration
> used in other languages.

I've hardly ever seen good code that actually uses that. And when it
did, it usually wasn't deliberate. Most well-written JS code will do
the same thing that Python code does, calling things that have already
been defined (if not lexically then temporally). No hoisting needed.

> I am now going to stop replying on this topic as I have said way too much
> and am not in particular disagreement if we are discussing preferences and
> ideas. I see TOOLS here, not religion. Use what works or that has to be used
> for a task but don't take any one thing too seriously.

Yes, I see tools too. And this thread started out with a discussion of
the for-else construct, which was disparaged because it violated a
rule that nobody here has heard of, few agree with, and has exceptions
already.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: for -- else: what was the motivation?

[avi.e.gross]

>>>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
or other advice that I simply ignore especially if it is about exotic herbs
to use or weird ideas like homeopathy or that I should use language X
because it is the only way to a haven or heaven or whatever.

What we had here was someone suggesting their advice was WELL-KNOWN followed
by lots of people sputtering about not having heard of it. I actually think
the advice would be reasonable in many circumstances as long as it did not
conflict with dozens of goals I find more compelling but which vary on a
case by case basis such as whether I am prototyping something I will use
once, ...

I have studied PHP but have never felt a need to use it and arguably the
roles it has played are often done commonly by other programs or methods.
Some people might say the same for many languages that are going extinct or
that have had to change and adapt to keep being relevant. Had the user
mention this was advice given regarding programs in the original BASIC or in
COBOL or PASCAL or lots of other languages I may have once used but rarely
see much point in caring about, it would be no different.

But having ONE source is troublesome. I mean most languages used will
suggest some form of making some kinds of variable names meaningful within
various constraints. The constraints may be that the maximum length is
bounded or that it cannot start with a number (or perhaps underscore) or
contain some characters. But other advice varies enough that there is no
RIGHT or WRONG across languages. I have seen suggestion to use camelCase or
use periods or underscores between parts of a variable name. I have seen
suggestions to use a unique prefix or suffix to mark all your own variables
as a way to minimize the chance of namespace collisions. Some languages
suggest or even enforce that some names be all upper case or have an initial
uppercase letter while others should be completely lower case. I mean things
like function names versus method names versus class names and so on. 

The more global advice is ADVICE that suggests whatever method you choose,
be consistent. If you make class names a certain way, do it as much as
possible for all class names and avoid doing the same thing for non-class
names. I think quite a few suggestions fall into the category that they are
similar or abstractly enough suggested in many programming languages and by
many people. There may be a big enough consensus, perhaps with some
outliers, that it may be accepted as reasonable advice to not be ignored
without good reasons. 

So in my view, the objection is not about PHP but about uniqueness. If the
author of one Python textbook and no others, suggest that your code should
declare all imports in alphabetical order then declare all functions in
alphabetical order, they can not only safely be ignored, but perhaps not
taken seriously as imports sometimes need to be done carefully if something
needs something else and if a language needs functions to be defined before
another function body calls them, ...

I was not questioning that someone had heard this advice somewhere and did
not just make it up. Others searching had trouble finding it but that does
not prove anything. Someone finally found one example, which is fine and I
suspect there may be other examples found if the search was broader. I
suspect there are plenty of places that advise that you should write such
code so the main things is visible on the current screen and not buried
deeply.

But some people seem to miss a point we have discussed. The odd clauses like
ELSE after a loop (and quite a few variants in similar and different cases)
often provide guarantees such as making sure a file opened is closed. If you
look at a Python protocol such as WITH, then things implementing it arrange
it so under most circumstances other than pulling a power line out of the
wall, the darn file gets closed no matter how you exit the area, and other
scenarios try to clean things up even as exceptions are being handled.
Sometimes not using these constructs and using something you think is
identical but looks better to you, can result in unanticipated behavior.
Putting items in a finally or other such clause can be meaningful and
sometimes makes some things quite explicit and reliable. 

Are these things out of the way? Yes, but so what? I see things as a whole
not as just a single screen shot. If a loop has several optional clauses lie
we are discussing and you know they are normally near the end, then look for
them where they are. 

I know some languages, JavaScript being an example, may have things you
might consider odd such as promoting some things like function definitions
found further in your code to near the top so 

RE: for -- else: what was the motivation?

[avi.e.gross]

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 PYTHON when writing code but 
an amalgam of many languages with all kinds of ways of doing things and then 
zoom in on how to do it in the current language be it Python or R or JavaScript 
and so on. Yes, I am in some sense focused but also open, just as in Human 
languages I may mostly be thinking in English but also sometimes see words and 
phrases pop into my mind from other languages that mean about the same thing 
and then filter it out to focus on whichever language I am supposed to be using 
at the time.

So back to the topic we are wandering in of what kinds of advice might apply in 
some complex nested IF-THEN-ELSE structures or CASE statements and so on such 
as comprehensions as to what ways produce better results much of the time and 
when another method is better.

Someone suggested a method they use that others wondered about. But they have a 
point. If you make code with large blocks that do not fit on your screen, and 
indentation is your guide, you can easily lose sight of things. 

But my advice given glibly is also not serious. Sometimes you may think you are 
being efficient and as DN pointed out, you are not. The compiler or other 
software may internally rearrange and optimize your code and make your method 
not necessary or even prevent the optimization. Your tradeoff may make a 
program run faster but use more memory or other resources or make it hard for 
anyone else (or yourself next week) to understand your code or be able to 
modify it. 

So, yes, sometimes it is more natural to write code like if score greater than 
90, give an A else if greater than 80 give a B, ... else if less than 65, give 
an F. Perhaps in Harvard your choice of grades is limited to mostly an A and a 
few B, no C/D as anything lower is an F. Some other school may have few A and 
mainly C.  It may be optimal to start with if between 70 and 80, give a C, then 
deal with lesser cases. Sometimes the data drives what is more common and hence 
more efficient.

But a big exception is cases where the program blows up if you are not careful. 
You cannot do certain thinks if a value is empty or NULL or an index above the 
length of something indexable or trying to write to something read-only and 
many more.

So much code may look like, in pseudocode:

Case
 is.na(var) do this
var > length do that
value[var] of type integer do whatever
...

It may take several steps to make sure your data won't cause an exception if 
queried without checking if the query makes sense. Only once that is away, 
might you be able to try for the most common cases for valid data first.

Again, as DN points out, in Python some may use exceptions that would jump in 
for the hopefully rare cases the above type of code tries to protect against. 
That can be a good approach if these cases are rare and identifiable as unique 
exceptions so your code focuses on optimizing the good cases you normally 
expect and shows them up-front with exception-handling code dangling beneath. 

I suspect some of us prefer some methods over others but can also be 
ambidextrous as needed. Older languages rapidly killed any program that tried 
to divide by zero so every single division needed to be protected if a zero 
might be involved. Mind you, newer languages can face serious bugs with things 
not easily trapped as value like Inf or NaN or missing values of various kinds 
can propagate and ruin lots of data. What is the mean of a group of numbers 
that includes an infinite one? What about some form of NA? Languages like R 
offer lots of idioms such as having many functions add a codicil like 
na.rm=TRUE that strips them before they infect your data, but that is not 
always appropriate.

I do not see most programming as a one-size-fits-all approach. Most advice is 
best ignored. Anyone who suggests that all functions be say no more than 5 
lines and that you should waste lots of time and energy making ever more small 
functions to decompose any larger one till it is under 5 lines but now calls 
lots of meaningless short functions sometimes 10 levels deep, is not helping 
you. Goals are fine when they make sense but often the opposite is true.

Consider some kind of case statement that has dozens of cases like asking what 
to do when one of many keys is pressed on a keyboard. The function can be 
dozens or hundreds of lines long. I could create a function that tests for 'A' 
and non-A and in the latter case calls a second function that tests for B and 
non-B and so on. If the user types Z, it is handled in the 26th function! But 
worse, you may need to pass all kinds of other variables down this chain so 
whatever key is pressed can do things with local variables. This 

RE: for -- else: what was the motivation?

[avi.e.gross]

[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 where
an in-core data structure called a pipe was used to connect the output of
one process to the inputr of another, sometimes in long chains like:

 cat file1 file2 file3 | grep pattern | ... | lp

Various utilities were thus linked to dynamically create all kinds of
solutions. Note the programs ran in parallel and if a program wrote too much
into a pipe, it was frozen till the program reading from the pipe caught up
a bit and vice versa. So it often ran a lot faster than earlier programs
that ran sequentially and each one wrote output (unbuffered) into a file and
the next program would read from the file. And, of course, there were no
files to clean up and it skipped expensive I/O to and from slow hard disks.

Languages like R had extensions added in various ways  within a process that
were very different. The parts ran sequentially but instead of writing:

Name1 <- func1(args)
Name2 <- func2(Name1, args)
rm(Name1)
Name3 <- func3(Name2, args)
rm(Name2)
...

You could use an add-on library called dplyr (or others) to do something
like this where to some extent it is syntactic sugar:

Result <- Mydata %>% func1(remaining_args) %>% func2(remaining-args) %>%
func3(remaining-args)

A practical example would often be written like this using a dta.frame
called Mydata that has rows and columns:

Mydata <-
Mydata %>%
select(columns-to-keep) %>%
rename(columns-to-change) %>%
filter(conditions-on-which-rows-to-keep) %>%
mutate(newcol=calculation, newcol=calculation, ...) %>%
group_by(column, column, ...) %>%
summarize(...) %>%
arrange(col, desc(col), ...) %>%
ggplot(...) + ...

There are many verbs that take your data one step at a time and keep
transforming it. The output of each step becomes the hidden first argument
of the next step. Not the same kind of pipeline. R recently added a native
pipe character so you might use the |> symbol now. It is not quite the same
but often faster.

So finally getting to how Python (and JavaScript and many others) do
something vaguely similar in the sense of chaining. 

If you have an object with some method you can call on it (or in some cases
a normal function call) that returns  another (or the same) object, then you
can write code like:

This.that.other


One obvious example that is trivial is an object that contains another
object which contains yet another object with attributes. Saying
a.b.c.attribute is not really a pipeline but simply multiple lines of code
collapsed into one fairly logical bundle. Similarly you can do
a.method().method().method() where each method is called on whatever object
the preceding method returned which is something "this" in whatever
language.

The pandas module is designed to make such pipelines doable as many methods
return the object being worked on.

 But consider an example in base Python  like a text object that has a
method to format as in :

"My name is {fname}, I'm {age}".format(fname = "John", age = 36)

The result is another string which can then be trimmed or split into parts
placed in a list and the list can be asked to do something like throw away
the 4th item or remove duplicates or be sorted and several more steps like
that using a period to apply some functionality to the current state of the
current object.

For those who use the python sklearn module, it has a vaguely different idea
of a pipeline as in specifying a set of transformations to be done so the
result of each step is passed as the input of the next step. You don't do
the steps yourself, as much as pass a set of functions to an object that
stores them until you ask it to perform an evaluation and then it processed
your data using those chained functions which can dynamically change. Lots
of machine learning algorithms use similar ideas such as neural networks
that propagate data/impulses along a chain of filters and so on.

For anyone still reading, the original point must be restated. My point was
some people like to program in small byte-size units as if still writing
their first BASIC program. When I use a pythonic idiom (or in R or other
languages whatever they consider a good way to use the language) they want
it dumbed down into simple single lines even in code like:

 a, b = b, a

They would rather use:

 temp = a
 a = b
 b = temp

You get the idea. So I have had some nice compact code re-arranged to be
much larger and sometimes harder to read and follow. So advice on a goal to
make the early blocks of code smaller than later ones may not work when
someone changes your code to their wishes!

End of digression. Again, not all meanings of pipeline are even close to
being the same.


-Original Message-
From: Python-list  On

Re: for -- else: what was the motivation?

[Chris Angelico]

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 want to know... Played Duck, duck, go on this: zero hits
> > amongst a pile of similar phrases - turns-out there's an algorithm with
> > a similar name, but not related, and an electronics approach (way too
> > 'low' a level for translation to us though).
> >
> > Tried prefixing with "program" but no such advice to programmers or
> > program[me] designers.
> >
> > Tried prefixing with "python", but equal lack of joy.
> >
> > Would OP please quote source?
> >
> [snip]
> After a few minutes searching I found this:
>
> https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/CodingGuidelines/CglPhp/PhpFileFormatting/PhpSyntaxFormatting.html
>
> """It is recommended to create conditions so that the shortest block of
> code goes first."""

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[dn]

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 this: zero hits
amongst a pile of similar phrases - turns-out there's an algorithm with
a similar name, but not related, and an electronics approach (way too
'low' a level for translation to us though).

Tried prefixing with "program" but no such advice to programmers or
program[me] designers.

Tried prefixing with "python", but equal lack of joy.

Would OP please quote source?


[snip]
After a few minutes searching I found this:

https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/CodingGuidelines/CglPhp/PhpFileFormatting/PhpSyntaxFormatting.html

"""It is recommended to create conditions so that the shortest block of 
code goes first."""


Thanks for this!

So, a Domain-Specific Language for a CMS.

If this is only reference, then hardly a tenet of ComSc thinking or 
programming-languages!



For fun: Typo3 is based on PHP. Advice (apparently) not replicated in 
PHP-docs (if, else, etc).

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Thomas Passin]

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 don't think that one-liner solves Antoon's requirement of continuing
> after an error. It uses just the normal python parser so it has exactly
> the same limitations.

Yes, of course. Interesting, though. py_compile tends to be what I use 
for a quick check. I linked to the page mostly for the other 
possibilities, as you mentioned below:


> Some of the mentioned tools may do what Antoon wants, though.
>
>  hp
>
>

--
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[MRAB]

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 similar phrases - turns-out there's an algorithm with
a similar name, but not related, and an electronics approach (way too
'low' a level for translation to us though).

Tried prefixing with "program" but no such advice to programmers or
program[me] designers.

Tried prefixing with "python", but equal lack of joy.

Would OP please quote source?


[snip]
After a few minutes searching I found this:

https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/CodingGuidelines/CglPhp/PhpFileFormatting/PhpSyntaxFormatting.html

"""It is recommended to create conditions so that the shortest block of 
code goes first."""

--
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[dn]

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 there's an algorithm with 
a similar name, but not related, and an electronics approach (way too 
'low' a level for translation to us though).


Tried prefixing with "program" but no such advice to programmers or 
program[me] designers.


Tried prefixing with "python", but equal lack of joy.

Would OP please quote source?


On 10/10/2022 05.56, Peter J. Holzer wrote:

On 2022-10-09 12:18:09 -0400, Avi Gross wrote:

Smallest code blocks first may be a more modern invention.


None of the recent-grads or new-hires I've asked this morning (it's 
already Monday over-here!) have used or heard the term.




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 the rarer cases especially the ones that should
never happen.


Those of us who started programming on 8 bit homecomputers of course
have efficiency always at the back of their heads, but I find this


... for mainframes just as much as micro-computers!

Regarding execution-efficiencies, I'm sure @Avi knows better than I: It 
seems likely that Python, as an interpreted language, will create 
'blocks' of its virtual-machine code in the same order as they appear in 
the Python-source. However, aren't there optimising compilers which do 
something intelligent with the equivalent clauses/suites in other languages?


Regardless, is a Jump-instruction which transfers else-control to a 
block five machine-instructions 'down', any less efficient than a jump 
which spans 50-instructions?




So not a rule but realistically not always a bad idea to write code in a
way that draws the attention of readers along the main path of execution
and perhaps not showing all the checking for odd cases first.


much more important. Putting the main path first makes it easier to
understand what the code is supposed to do normally. All those pesky
exceptions are in the "small print" below.


Absolutely! Has the term "readability" been used 'here'?

Human nature (or is it that of computer programmers in-particular) is to 
be optimistic: it will work [this time*]. Accordingly, a colleague talks 
of always coding 'the happy line' first (meaning line of logic, cf 
source-code).


Contrarily, for while-True (infinite) loops, and particularly recursive 
algorithms, the [wise] counsel is to code the end-condition first. 
(always know your closest exit! "The nearest exit may be behind you"...)



Indeed, dare I say, this optimistic-approach is pythonic. Taking an 
over-simple, two-value division example, the approach is:


try:
a = b / c
except ZeroDivisionError:
... clean-up the mess ...

which contrasts the EAFP philosophy of Python versus the LBYL 
expectation of (many) other languages:


assert c != 0
a = b / c

That said, as "Data Science" use of Python expands, it is bringing more 
and more needs for an LBYL attitude, eg "data cleaning".


(EAFP, LBYL? https://docs.python.org/3.9/glossary.html)



There is of course the opposite view that you should just get all of the
confounding factors out of the way first, so that the default is also
the common case. I also do that sometimes, but then I don't hide this in
in an else: clause but do something like this:

for item in whatever:
 if not_this_one(item):
 continue
 if neither_this_one(item):
 continue
 if cant_continue(item):
 break
 if oopsie():
 raise SomeError()

 do_something_with(item)
 and_some_more(item)
 we_are_done(item)

which shows visually what the main purpose of the loop (or function or
other block) is.


Nicely stated!

NB I've seen sufficient of @Peter's posts to know that this was never 
(even implied to be) intended as a snippet for all occasions!



It also illustrates why such is less readable: because we have to scan 
four if-statements before we can 'see' the purpose of the loop. My 
'itch' would be to extract this code 'out' to a function - that way the 
name will convey the somewhat-obscured purpose of the loop.



Alternately, reduce the 'distractions':-

try:
for item in whatever:
inspect_the_data( item )
do_something_with(item)
and_some_more(item)
we_are_done(item)
except SomeError:
...
except CustomBreakException:
... ?pass?  # same effect as break

by 'hiding' in:

def inspect_the_data( item ):
if not_this_one(item):
continue
if neither_this_one(item):
continue
if cant_continue(item):
raise CustomBreakException  # was break
if oopsie():
raise SomeError()

Re: What to use for finding as many syntax errors as possible.

[Cameron Simpson]

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 their work each time a bug is 
corrected.


It is easy to get the syntax right before submitting to such a pipeline.  
I usually run a linter on my code for serious commits, and I've got a 
`lint1` alias which basicly runs the short fast flavour of that which 
does a syntax check and the very fast less thorough lint phase.


I say this just to ease your write/run-tests cycle.

Regarding your main request, had you considered writing your own wrapper 
tool? Something which ran something like:


python -We:invalid -m py_compile your_python_file.py

If there's an error, report it, then make a new file commencing with the 
next unindented line after the error, with all preceeding lines 
commented out (to keep the line numbers the same). Then run the check 
again. Repeat until the file's empty or there are no errors.


This doesn't sound very complex.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Chris Angelico]

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 non-syntactic error, but an error of syntax *by definition*
makes parsing the rest of the file dubious. What would it even *mean*
to not give up? How should it interpret the following lines of code?
All it can do is report the error.

You know, if you'd not made this thread, the time you saved would have
been enough for quite a few iterations of "fix one syntactic error,
run it again to find the next".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Karsten Hilbert]

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 you want to allow.
>
> Look when I was at the university we had to program in Pascal and
> the compilor we used continued parsing until the end. Sure there
> were times that after a number of reported errors the number of
> false positives became so high it was useless trying to find the
> remaining true ones, but it still was more efficient to correct the
> obvious ones, than to only correct the first one.
>
> I don't need to be sure. Even the occasional wrong correction
> is probably still more efficient than quiting after the first
> syntax error.

A-ha, so you further defined your context.

Under which I can agree to the objective :-)

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Barry]

> 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 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 python strategy which 
>>> quits
>>> after having found one syntax error.
>> 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 you want to allow.
> 
> Look when I was at the university we had to program in Pascal and
> the compilor we used continued parsing until the end. Sure there
> were times that after a number of reported errors the number of
> false positives became so high it was useless trying to find the
> remaining true ones, but it still was more efficient to correct the
> obvious ones, than to only correct the first one.

If it’s very fast to syntax check then one at a time is fine.
Python is very fast to syntax check so I personal do not need the multi error 
version.
My editor has syntax check on a key and it’s instant to drop me a syntax error.

Barry

> 
> I don't need to be sure. Even the occasional wrong correction
> is probably still more efficient than quiting after the first
> syntax error.
> 
> -- 
> Antoon.
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Antoon Pardon]

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 such a tool doesn't need to go through all the provided 
information.
If after correcting a few errors, the users find the rest of the information 
gives
him a headache, he can just ignore all that and just run a new iteration.

--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Peter J. Holzer]

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 |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Peter J. Holzer]

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 a less stable place.
> 
> Interpreters for Python have to catch interrupts as they go and often run
> code in small batches. Continuing to evaluate after an error could cause
> weird effects.

I don't think this is really an issue. A python file is completely
compiled to byte code before execution starts.

It's true that a syntax error before an import prevents that import, but
since imports are usually at the start of a file, a syntax error will
only rarely prevent the import (and files intended to be imported
generally don't have weird side effects anyway).

One issue is could be that compilers which generate executables are
generally thorough and slow, while the compilers which generate
byte-code for immediate consumption by an interpreter are generally
simple and fast. So there is more incentive for the former to discover
as many errors as possible and they are also better equipped to do this.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Antoon Pardon]

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 stable place.

Interpreters for Python have to catch interrupts as they go and often run
code in small batches. Continuing to evaluate after an error could cause
weird effects.

So what you want is closer to a lint program that does not run code at all,
or merely writes pseudocode to a file to be run faster later.


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.


I will say that often enough a program could report more possible errors.
Putting your code into multiple files and modules may mean you could
cleanly evaluate the code and return multiple errors from many modules as
long as they are distinct. Finding all errors is not possible if recovery
from one is not guaranteed.


I don't need it to find all errors. As long as it reasonably accuratly
finds a significant number of them.


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 their work each time a bug is corrected.

--
Antoon.
--
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Antoon Pardon]

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 stable place.

Interpreters for Python have to catch interrupts as they go and often run
code in small batches. Continuing to evaluate after an error could cause
weird effects.

So what you want is closer to a lint program that does not run code at all,
or merely writes pseudocode to a file to be run faster later.


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.


I will say that often enough a program could report more possible errors.
Putting your code into multiple files and modules may mean you could
cleanly evaluate the code and return multiple errors from many modules as
long as they are distinct. Finding all errors is not possible if recovery
from one is not guaranteed.


I don't need it to find all errors. As long as it reasonably accuratly
finds a significant number of them.


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 their work each time a bug is corrected.

--
Antoon.
--
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Avi Gross]

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 error report may
make me search for the others places so I fix it all at once. Telling me
where some instances are might speed that a bit.

As long as it is understood that further errors are a heuristic and
possibly misleading,  fine.

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.

But a tool like you described could have uses even if imperfect. If you are
teaching a course and students submit programs, could you grade the one
with a single error higher than one with 5 errors shown imperfectly and
fail the one with 600?

On Sun, Oct 9, 2022, 1:53 PM 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, 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 python strategy
> which quits
> >> after having found one syntax error.
> > 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 you want to allow.
>
> Look when I was at the university we had to program in Pascal and
> the compilor we used continued parsing until the end. Sure there
> were times that after a number of reported errors the number of
> false positives became so high it was useless trying to find the
> remaining true ones, but it still was more efficient to correct the
> obvious ones, than to only correct the first one.
>
> I don't need to be sure. Even the occasional wrong correction
> is probably still more efficient than quiting after the first
> syntax error.
>
> --
> Antoon.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Avi Gross]

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 style and abilities.
That meant removing most of my comments, renaming some variables, taking
out code that checked things like whether a file existed before opening it
and of course no pipelines. It had to be downgraded and had I known, I
could have easily given them code written as if it was in some poorer
language.

Python has idioms often used in making pipes of a sort but in languages
with other forms, such as R, debugging is not that difficult as you can
insert functions in middle of a pipeline that print what you want but
return the data structure they were fed for the next step in the pipeline.
When done, remove the lines with such entries or change the function
definition or something like that.

Objects used as pipelines do not do this as easily as you may need to add
methods ...


On Sun, Oct 9, 2022, 1:17 PM Peter J. Holzer  wrote:

> 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 have certainly done that (not with your code, AFAIK). The problem with
> those beautiful one-liners is that they are really hard to debug. So if
> I can't convince myself that they are correct just by reading them I
> have to split them over multiple lines so I can add breakpoints or log
> messages. Of course I could put it together again afterwards, but I
> would argue that if I didn't understand it the first time it's probably
> better to leave it in its more verbose and debuggable state.
>
> Of course I have also done the opposite: Taken some messy and
> complicated code and simplified it into a simple generator expression.
> In fact I would say that I code tends to be shorter after I fixed a bug
> than before.
>
>
> > So although size may matter, so can sighs.
>
> :-)
>
> hp
>
> --
>_  | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> __/   | http://www.hjp.at/ |   challenge!"
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[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 stable place.

Interpreters for Python have to catch interrupts as they go and often run
code in small batches. Continuing to evaluate after an error could cause
weird effects.

So what you want is closer to a lint program that does not run code at all,
or merely writes pseudocode to a file to be run faster later.

Many languages now have blocks of code that are not really be evaluated
till later. Some code is built on the fly. And some errors are not errors
at first. Many languages let you not declare a variable before using it or
allow it to change types. In some, the text is lazily evaluated as late as
possible.

I will say that often enough a program could report more possible errors.
Putting your code into multiple files and modules may mean you could
cleanly evaluate the code and return multiple errors from many modules as
long as they are distinct. Finding all errors is not possible if recovery
from one is not guaranteed.

Take a language that uses a semicolon to end a statement. If absent usually
there would be some error but often something on the next line. Your
evaluator could do an experiment and add a semicolon and try again. This
might work 90% of the time but sometimes the error was not ending the line
with a backslash to make it continue properly, or an indentation issue and
even spelling error. No guarantees.

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.

On Sun, Oct 9, 2022, 1:03 PM Antoon Pardon  wrote:

>
>
> 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 python strategy which
> quits
> after having found one syntax error.
>
> --
> Antoon.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: AWS upload script written in python - verify number of processes used

[jschwar]

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 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 know either.

 

Does anyone know how to check this?

 

 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Avi Gross]

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 only in critical
areas. The emphasis may be on the programmer experience in writing fast
code with fewer errors. Perhaps secondary but often important is making the
code maintainable and in my experience that can often be best done by
choosing meaningful names and brief selective comments than by worrying
about the size of blocks of code.

But others obviously preach what they think works for them even when it may
constrain others more than it helps.

I have seen people suggest that all variables have short names like a3 but
that does not mean it improves anything other than the size of the code and
parsing it. The loss in readability and so on probably is worse.


On Sun, Oct 9, 2022, 12:53 PM Chris Angelico  wrote:

> 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
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[MRAB]

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, 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 python strategy which quits
after having found one syntax error.

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 you want to allow.


Look when I was at the university we had to program in Pascal and
the compilor we used continued parsing until the end. Sure there
were times that after a number of reported errors the number of
false positives became so high it was useless trying to find the
remaining true ones, but it still was more efficient to correct the
obvious ones, than to only correct the first one.

I don't need to be sure. Even the occasional wrong correction
is probably still more efficient than quiting after the first
syntax error.

When I did some programming in COBOL, a single omitted "." would 
completely confuse the compiler and it was best to fix that one error 
and then try again.


On the other hand, TurboPascal would also stop on the first error and 
put the cursor at the error position in the IDE, but as it compiled 
quickly, it wasn't a problem. It was no slower than it would've been if 
it had found multiple errors and you pressed a key to advance to the 
next error.

--
https://mail.python.org/mailman/listinfo/python-list

AWS upload script written in python - verify number of processes used

[jschwar]

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 know either.

 

Does anyone know how to check this?

 

 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Weatherby,Gerard]

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: What to use for finding as many syntax errors as possible.
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

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. I just want a tool for syntax errors. No style
enforcements. Any recommandations? -- Antoon Pardon
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!kxDZilNf74VILuntVEzVZ4Wjv6RPr4JUbGpWrURDJ3CtDNAi9szBWweqrDM-uHy-o_Sncgrm2BmJIRksmxSG_LGVbBU$
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Antoon Pardon]

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 I would prefer a tool that reported 100 errors, which would
allow me to easily correct 10 real errors, over the python strategy which quits
after having found one syntax error.

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 you want to allow.


Look when I was at the university we had to program in Pascal and
the compilor we used continued parsing until the end. Sure there
were times that after a number of reported errors the number of
false positives became so high it was useless trying to find the
remaining true ones, but it still was more efficient to correct the
obvious ones, than to only correct the first one.

I don't need to be sure. Even the occasional wrong correction
is probably still more efficient than quiting after the first
syntax error.

--
Antoon.
--
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Peter J. Holzer]

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.
> >
> > At this moment I would prefer a tool that reported 100 errors, which would
> > allow me to easily correct 10 real errors, over the python strategy which 
> > quits
> > after having found one syntax error.
> 
> But the point is: you can't (there is no way to) be sure the
> 9+ errors really are errors.

As a human who knows Python in many cases you can be sure. Sometimes you
aren't sure, then you leave that one for the next iteration. No big
deal. This isn't the 1960s when you sent your punched cards in and got
the result back next week. So neither the parser nor you need to be
perfect. Just better than one error at a time.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Peter J. Holzer]

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 continuing
after an error. It uses just the normal python parser so it has exactly
the same limitations.

Some of the mentioned tools may do what Antoon wants, though.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[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 I would prefer a tool that reported 100 errors, which would
> allow me to easily correct 10 real errors, over the python strategy which 
> quits
> after having found one syntax error.

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 you want to allow.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Thomas Passin]

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 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. I just want
a tool for syntax errors. No style enforcements. Any recommandations?


There seems to have been increased interest in good error recovery over
the last years. I thought I had bookmarked a bunch of projects, but the
only one I can find right now is Lezer
(https://marijnhaverbeke.nl/blog/lezer.html) which is part of the
CodeMirror (https://codemirror.net/) editor. Python is listed as a
currently supported language, so you might want to check that out.

Disclaimer: I haven't used CodeMirror, so I can't say anything about
its quality. The blog entry about Lezer was interesting, though.

 hp




--
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Peter J. Holzer]

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 have certainly done that (not with your code, AFAIK). The problem with
those beautiful one-liners is that they are really hard to debug. So if
I can't convince myself that they are correct just by reading them I
have to split them over multiple lines so I can add breakpoints or log
messages. Of course I could put it together again afterwards, but I
would argue that if I didn't understand it the first time it's probably
better to leave it in its more verbose and debuggable state.

Of course I have also done the opposite: Taken some messy and
complicated code and simplified it into a simple generator expression.
In fact I would say that I code tends to be shorter after I fixed a bug
than before.


> So although size may matter, so can sighs.

:-)

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[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 errors, which would
allow me to easily correct 10 real errors, over the python strategy which quits
after having found one syntax error.

--
Antoon.

--
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Peter J. Holzer]

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 common cases first. Those shorten
> execution more often than the rarer cases especially the ones that should
> never happen.

Those of us who started programming on 8 bit homecomputers of course
have efficiency always at the back of their heads, but I find this

> So not a rule but realistically not always a bad idea to write code in a
> way that draws the attention of readers along the main path of execution
> and perhaps not showing all the checking for odd cases first.

much more important. Putting the main path first makes it easier to
understand what the code is supposed to do normally. All those pesky
exceptions are in the "small print" below.

There is of course the opposite view that you should just get all of the
confounding factors out of the way first, so that the default is also
the common case. I also do that sometimes, but then I don't hide this in
in an else: clause but do something like this:

for item in whatever:
if not_this_one(item):
continue
if neither_this_one(item):
continue
if cant_continue(item):
break
if oopsie():
raise SomeError()

do_something_with(item)
and_some_more(item)
we_are_done(item)

which shows visually what the main purpose of the loop (or function or
other block) is.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Axy via Python-list]

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 you're paid for SLOC :-)))

By the way, does "else" clause after affect cyclomatic complexity 
metric? I mean "for" loops.


Axy.

--
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Chris Angelico]

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

Re: for -- else: what was the motivation?

[Avi Gross]

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 example, if something is expected to
rarely or never happen, code within that branch may not be needed to be
optimized in any way as long as it works in the remote chance it is called.

I think what was suggested here is more about code readability
considerations and for some of us, making us stand on our heads to puzzle
things out is harder than ordering longer items ...

On Sun, Oct 9, 2022, 12:30 PM Chris Angelico  wrote:

> 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 common cases first. Those shorten
> > execution more often than the rarer cases especially the ones that should
> > never happen.
> >
>
> Seems fairly dubious and full of special-cases. If you want to follow
> that rule, it should be easy enough to still permit for-else clauses.
> It's an extremely weak argument against for-else.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Avi Gross]

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 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.

So although size may matter, so can sighs.

On Sun, Oct 9, 2022, 4:24 AM Peter J. Holzer  wrote:

> 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 an if/elif/else statement by
> length seems like ordering books by color: It may be pretty, but it
> doesn't make them easy to find.
>
> hp
>
> --
>_  | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> __/   | http://www.hjp.at/ |   challenge!"
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Chris Angelico]

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 common cases first. Those shorten
> execution more often than the rarer cases especially the ones that should
> never happen.
>

Seems fairly dubious and full of special-cases. If you want to follow
that rule, it should be easy enough to still permit for-else clauses.
It's an extremely weak argument against for-else.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Karsten Hilbert]

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" statement and I overlooked that 
> even after
> re-reading the language reference. If "else" was named like 
> "never_broken_loop" or
> "nobreak", the semantic would be perfectly clear. But, what's done is done.

Or, "eventually". Sadly, "finally" is already taken, and with
slightly different semantics...

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Avi Gross]

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 the rarer cases especially the ones that should
never happen.

There are obvious exceptions like the default having to be last, albeit
some languages allow the default to be inserted anywhere visually even if
the code sort of runs last.

But negating a condition so smaller code appears first may have some cost.
I mean if !function() may be slower as the negating is an extra step. But
it may be even slower if the inversion is done using a wrapper function
that simply inverts the return value from the other function.

I think sometimes a comment placed carefully that explains the code and
logic in concise form is a simpler approach that can be followed by a big
chunk then little chunk without loss of readability.

In the original example the else part can be mentioned before the loop as a
sort of reminder.

In my experience, the size of code often varies within a project so a
smaller chunk may grow as requirements change, such as adding debug or
logging, and large chunks can shrink as common parts of the code get
extracted into functions.

So not a rule but realistically not always a bad idea to write code in a
way that draws the attention of readers along the main path of execution
and perhaps not showing all the checking for odd cases first. I mean as an
example if the argument is of type text then do stuff, else if a number
else if a symbol else if empty  ...

On Sun, Oct 9, 2022, 1:18 AM Chris Angelico  wrote:

> On Sun, 9 Oct 2022 at 16:05, Axy via Python-list 
> wrote:
> >
> >
> > On 09/10/2022 05:47, Chris Angelico wrote:
> > > On Sun, 9 Oct 2022 at 15:39, Axy via Python-list <
> python-list@python.org> wrote:
> > >> Got it, thanks!
> > >>
> > >> Actually the reason I never used "else" was the violation of the rule
> of
> > >> beauty "shortest block first". With if--else you can easily follow
> this
> > >> rule by inverting "if" expression, but with for--else you can't. The
> > >> loop body of the simplest example is already three lines, in real life
> > >> things are much worse.
> > >>
> > > That's not a rule I've ever been taught; how important is it?
> > >
> > > ChrisA
> >
> > It gets important if the lifetime of your project is more than three
> > months and is extremely important if more than 10 years. But, it depends.
>
> 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 in the literature from the old
> > good "How to write unmaintainable code" to "The Art of Readable Code".
> > And I hope there are a lot of recent books on this subject I did not
> > track and read yet.
>
> Also not really a justification for "shortest block first". Wanting
> some elaboration on that. What's the value in it?
>
> Given that for-else is an excellent, if rarely-used, construct, I
> would say that, *at least*, it is worth setting aside this rule for
> that particular situation. It is also generally worth using fewer
> commas than I just did. Take my advice with a grain of salt.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Peter J. Holzer]

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 python strategy of quiting after the first syntax error. I just want
> a tool for syntax errors. No style enforcements. Any recommandations?

There seems to have been increased interest in good error recovery over
the last years. I thought I had bookmarked a bunch of projects, but the
only one I can find right now is Lezer
(https://marijnhaverbeke.nl/blog/lezer.html) which is part of the
CodeMirror (https://codemirror.net/) editor. Python is listed as a
currently supported language, so you might want to check that out.

Disclaimer: I haven't used CodeMirror, so I can't say anything about
its quality. The blog entry about Lezer was interesting, though.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Avi Gross]

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 resume checking the
next function.  But what if a function defines local functions within it?
What if the mistake in one line of code could still allow checking the next
line rather than skipping it all?

My guess is that finding 100 errors might turn out to be misleading. If you
fix just the first, many others would go away. If you spell a variable name
wrong when declaring it, a dozen uses of the right name may cause errors.
Should you fix the first or change all later ones?



On Sun, Oct 9, 2022, 6:11 AM 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 python strategy of quiting after the first
> syntax error. I just want a tool for syntax errors. No style
> enforcements. Any recommandations? -- Antoon Pardon
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Michael Speer]

>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 ordering by block size


On Sun, Oct 9, 2022 at 2:26 AM Axy via Python-list 
wrote:

>
> > 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 in the literature from the old
> >> good "How to write unmaintainable code" to "The Art of Readable Code".
> >> And I hope there are a lot of recent books on this subject I did not
> >> track and read yet.
> > Also not really a justification for "shortest block first". Wanting
> > some elaboration on that. What's the value in it?
>
> Well, the value is productivity. No need to save puzzles "what this
> hanging else belongs to?" regardless of semantic, which ideally should
> not be a puzzle as well. Code small things first and return early, same
> as taking a test: do easy and quick things first and boring and
> difficult ones later.
>
> Axy.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

What to use for finding as many syntax errors as possible.

[Antoon Pardon]

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. I just want a tool for syntax errors. No style 
enforcements. Any recommandations? -- Antoon Pardon

--
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Peter J. Holzer]

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 an if/elif/else statement by
length seems like ordering books by color: It may be pretty, but it
doesn't make them easy to find.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Axy via Python-list]

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 in the literature from the old
good "How to write unmaintainable code" to "The Art of Readable Code".
And I hope there are a lot of recent books on this subject I did not
track and read yet.

Also not really a justification for "shortest block first". Wanting
some elaboration on that. What's the value in it?


Well, the value is productivity. No need to save puzzles "what this 
hanging else belongs to?" regardless of semantic, which ideally should 
not be a puzzle as well. Code small things first and return early, same 
as taking a test: do easy and quick things first and boring and 
difficult ones later.


Axy.
--
https://mail.python.org/mailman/listinfo/python-list