On 11/07/2020 06:22, Олег Комлев wrote:

...

ELSE-clause in FOR and WHILE has unclear syntax. I suggest new clause instead:

if COND: ... [elif COND: ...] [else: ...]

This IF-clause like must be immediately after FOR- or WHILE-cycle (only comment allowed between). It looks like a regular IF, but COND is special.

On Sun, Jul 12, 2020, at 00:16, Rob Cliffe via Python-ideas wrote:

Something to consider: Would it be legal to mix these CONDs with other conditions in the 'elif' chain? E.g. if break: ... elif x > 0: ... elif finally:

What if "instead of a special kind of if clause that can only be placed after a loop", we simply defined these three special expressions [usable in any if/elif statement] to reference special boolean flags that are set after exiting any loop?

What about adding `except` to the compound loop statement? That way in cases where there needs to be clarity you can raise a specific exception rather than just `break`. Keeping the logic of why you "break" the loop inside the loop and would also allow multiple reasons for breaking from a for loop to remain clear. e.g.

for i in range(N): if i > 3: raise ValueError except ValueError: print(i) # >> 4 else: print("Loop not entered")

On Tue, 14 Jul 2020 at 05:33, Ethan Furman wrote:

On 07/11/2020 09:16 PM, Rob Cliffe via Python-ideas wrote:

...

My gut feeling (backed by no evidence) is that dealing with the case of zero iterations is not needed frequently enough to cater for it.

My personal experience is that the case of no iterations is frequent enough, and a big enough pain to deal with, that if we're making changes we should include a way to deal with it. Currently:

if empty_iterable: # do whatever else: for it in iterable: # do something

or maybe:

obj = object for obj in some_iterator: do_stuff() if obj is object: # iterator was empty do_different_stuff()

Either way,

for obj in iterator: do_stuff elif empty: do_other_stuff()

would be much nicer.

-- ~Ethan~ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/W4C6TN... Code of Conduct: http://python.org/psf/codeofconduct/

-- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

On Tue, 14 Jul 2020 at 12:38, Dominik Vilsmeier wrote:

On 14.07.20 09:54, Mathew Elman wrote:

What about adding `except` to the compound loop statement? That way in cases where there needs to be clarity you can raise a specific exception rather than just `break`. Keeping the logic of why you "break" the loop inside the loop and would also allow multiple reasons for breaking from a for loop to remain clear.

e.g.

...

for i in range(N): if i > 3: raise ValueError except ValueError: print(i) # >> 4 else: print("Loop not entered")

That can be done already today by putting the `for` loop in the `try` body.

It can, but my thought was that this would be sugar that made it easier to follow the logic

Also here `else` should rather mean `did not raise` as for the normal `try/except/else` usage (and similar to how `for/else` means `did not break`).

Yes sorry, I made an error. I confused myself about what else does, how ironic. This would be most useful for cases where break and not breaking were unclear.

The more interesting part is to detect whether the loop did some work at all (i.e. whether the iterable was empty).

This could be done by raising a "silent" exception that is handled by default (something like StopIteration), when trying to iterate an empty iterable. If the "NoIteration" exception is not caught explicitly it is ignored. Then you could have :

for i in range(N): if i > 3: raise ValueError except ValueError: print(f"{i} is more than 3") except NoIteration: print("Loop not entered") else: print(f"{i} is less than 4")

This may not be to everyone's taste, but to me it's better than the current state of things and clearer than having special if statements after a loop.

But also this can be done with some small overhead:

loop = Loop(iterable) for x in loop: pass if loop.empty: pass

The `Loop` class here wraps the sentinel logic required to detect if the iterable was empty.

_______________________________________________

Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ICALEM... Code of Conduct: http://python.org/psf/codeofconduct/

-- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

But in `for...else` the `else` call isn't always called, so changing `else` for `finally` doesn't make sense. What you're suggesting is replacing `else` with `on_finish` and adding `finally` and `on_break`. I agree that having `finally` could make the use cases of `else` clearer, but I am not convinced renaming "else" to "on_finish" would help the confusion for the 0 iteration case. I think that since this suggestion doesn't help with the 0 iteration case (my first idea here didn't either), it feels like added extra compound statements need to be immediately intuitive to be worth having - either because they read like a sentence or parallel existing python e.g. `try-except-else-finally` or `if-elif-else` etc. On Wed, 15 Jul 2020 at 06:47, Steve Barnes wrote:

Can I suggest that for loops the `else` would be a lot clearer if it was spelt `finally` as was done for PEP-0341 for try blocks and that we might possibly need one or more `on_…` clauses such as `on_break` and `on_finish` I think that this would be a lot clearer:

for i in range(N):

if i > 3:

break;

on_break: # Called if loop was broken

print(i)

on_finish: # Called if loop was not broken

print("Loop Completed")

finally: # Always called (replaces for…else)

print("Loop Ended")

Which I think would be a lot easier for newcomers to learn than try…for…else…except…else e.g.:

try:

for i in range(N):

if i > 3:

break;

elif i % 2 == 0:

raise ValueError("Odds Only");

else: # to if

print(i)

else: # Else to loop

print("Loop Completed")

except ValueError as err:

print(err)

else: # to try

print("No Exception")

finally:

print("Try Ended")

Where the multitude of elses makes my eyes cross.

Steve Barnes _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MKAAWV... Code of Conduct: http://python.org/psf/codeofconduct/

-- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

The point is that `for-else` reads like "do this for loop ELSE (or but if you can't loop) do this", i.e. roughly equivalent to this:

try: loop_entered = False for loop_entered, elem in enumerate(iterable, start=1): pass assert loop_entered except AssertionError: print("loop not entered")

or

loop_entered = False for loop_entered, elem in enumerate(iterable, start=1): pass if loop_entered: pass else: print("loop not entered")

But that isn't what it means. It means "do this for loop and if you deliberately break out, continue ELSE (or if you don't break out) do this". i.e. roughly equivalent to this:

loop_broken = False for elem in iterable: if should_break(elem): loop_broken = True break if not loop_broken: print("you didn't break from the loop you maybe entered...")

or

loop_broken = False for elem in iterable: if should_break(elem): loop_broken = True break if loop_broken:

pass

else:

print("you didn't break from the loop you maybe entered...")

which is not intuitive because `else` reads like it handles the unexpected case, which one would have guessed was either breaking out or not entering in the first place. On Wed, 15 Jul 2020 at 09:23, Dominik Vilsmeier wrote:

But `finally` with a `for` loop is redundant since the code can be placed just after the loop. For `try/except` it's a different situation since the exception might bubble up, so "normal" code after the `try` won't be reached.

Also `on_break` doesn't seem really important since that code can be executed inside the loop right before the `break`.

We already have `else` for `on_finish` and I think when recalling the analogy to exceptions it's not that confusing: a `try` block can be exited either normally (because all code has been executed) or because it raised an exception; here `else` means it exited normally. Similarly a `for` loop can terminate either normally by executing all iterations or because a `break` occurred; and similarly `else` means it terminated normally. On 15.07.20 08:47, Mathew Elman wrote:

But in `for...else` the `else` call isn't always called, so changing `else` for `finally` doesn't make sense. What you're suggesting is replacing `else` with `on_finish` and adding `finally` and `on_break`.

I agree that having `finally` could make the use cases of `else` clearer, but I am not convinced renaming "else" to "on_finish" would help the confusion for the 0 iteration case.

I think that since this suggestion doesn't help with the 0 iteration case (my first idea here didn't either), it feels like added extra compound statements need to be immediately intuitive to be worth having - either because they read like a sentence or parallel existing python e.g. `try-except-else-finally` or `if-elif-else` etc.

On Wed, 15 Jul 2020 at 06:47, Steve Barnes wrote:

...

Can I suggest that for loops the `else` would be a lot clearer if it was spelt `finally` as was done for PEP-0341 for try blocks and that we might possibly need one or more `on_…` clauses such as `on_break` and ` on_finish` I think that this would be a lot clearer:

for i in range(N):

if i > 3:

break;

on_break: # Called if loop was broken

print(i)

on_finish: # Called if loop was not broken

print("Loop Completed")

finally: # Always called (replaces for…else)

print("Loop Ended")

Which I think would be a lot easier for newcomers to learn than try…for…else…except…else e.g.:

try:

for i in range(N):

if i > 3:

break;

elif i % 2 == 0:

raise ValueError("Odds Only");

else: # to if

print(i)

else: # Else to loop

print("Loop Completed")

except ValueError as err:

print(err)

else: # to try

print("No Exception")

finally:

print("Try Ended")

Where the multitude of elses makes my eyes cross.

Steve Barnes _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MKAAWV... Code of Conduct: http://python.org/psf/codeofconduct/

Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.

If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.

References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3ZPJDO... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/W7M77O... Code of Conduct: http://python.org/psf/codeofconduct/

-- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

On Wed, Jul 15, 2020 at 05:45:05AM +0000, Steve Barnes wrote:

Can I suggest that for loops the `else` would be a lot clearer if it was spelt `finally` as was done for PEP-0341 for try blocks and that we might possibly need one or more `on_…` clauses such as `on_break` and `on_finish` I think that this would be a lot clearer:

Sorry Steve, "finally" would be a terrible name because it behaves nothing like try...finally. In try blocks, the finally block is *always* executed, even if you raise, even if you return. (To be precise, there are odd and unusual cases where finally won't be executed, such as if the interpreter process is `kill -9`'ed, or if a power surge fries the CPU. But under normal processing, finally always runs.) But the for...finally (renamed from for...else) is not like that. If anything, it's the opposite of finally: it is a block designed to be skipped, not a block designed to always run. Any of `break`, `return` or `raise` will cause the for...finally clause to be skipped. So we would be swapping one form of confusion to another ("why is my finally clause not executed?"). -- Steven

Thank to all disputants. It is possible to borrow the keyword "case" from PEP-622 (when it appears https://www.python.org/dev/peps/pep-0622). Keyword "case" can be written instead of "else/elif". I.e. case COND: ... [case COND: ...] [case COND: ...] All conditions COND must be different. Last "case COND:" can be replaced with "else:".

On Sun, 19 Jul 2020 at 15:43, Олег Комлев wrote:

Thank to all disputants. It is possible to borrow the keyword "case" from PEP-622 (when it appears https://www.python.org/dev/peps/pep-0622). Keyword "case" can be written instead of "else/elif". I.e. case COND: ... [case COND: ...] [case COND: ...] All conditions COND must be different. Last "case COND:" can be replaced with "else:".

For me this is -1 because "for... case" and "while... case" don't read like english. I also think the issue is less what keyword is used from "case", "if", "except" or "joojoo" rather what the "COND" look like. Obviously this depends on what the keyword is e.g. for "case"/"if" they should be predicates, for "except" they should be exceptions and if adding a new keyword it may be they are not needed. But I would say deciding on those is the priority. Side Note: It does feel like "elif" should be part of the "for-else" and "while-else" (especially while) compound statements. -- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

This is a continuation of my previous post to this thread. Python's FOR ... ELSE ... , Raymond Hettinger has told us, has origins in some ideas of Don Knuth. For that reason, and others, I'll concisely review these ideas. In the very early days, a computer program was a sequence of commands. The goto <somewhere> command was used to create loops, and the IF command was used to break from loops. Often, this led to what was called spaghetti code. (In some versions of BASIC, the GOTO was to a line number.) In the 1960's ideas developed to remedy this situation. Edsger Dijkstra coined the phrase 'structured programming', and he was the author of the famous paper 'Go To Statement Considered Harmful'. (I recall reading that the title was supplied by Wirth.) Aside: This is in the context of source code. By 1970 there were higher level languages, which were compiled into machine code. Dijstraka I'm sure approved, within limits, of GOTO in machine code. One consequence of structured programming is to provide and guarantee such limits. Don Knuth's 1974 paper, Structured Programming with goto statements, finds merit in both sides of the question. One of his goals is "improved syntax for iterations and error exits, making it possible to write a larger class of programs clearly and efficiently without goto statements". Nearly done with the review. Knuth finds a result of Lipton, Eisenstadt and DeMillo especially noteworthy. Briefly, for every large n, there is an n-statement program using goto statements that cannot be 'nicely converted' to a structured program. By 'nicely converted' (my phrase) Knuth means that the structured program is either larger or slower or both than the goto program, with a numeric lower bound on by how much. (Size exponential in n, speed logarithmic in n, both with explicit constants.) This justifies Knuth's phrase "a larger class of programs" in the goal I just stated. Aside: Incidentally, Knuth's paper uses coroutines in his discussion of efficient implementation of Hoare's quicksort algorithm. In it he credits Strachey sharing with Knuth the importance of coroutines (or goto) for producing a conceptually simple solution to the problem of merging two binary trees. It might help if a tutorial on how to do this in Python, by using async and wait, was written. My next post will apply some of the concepts in Knuth's goto paper to FOR ... ELSE ... in Python. The above relies on a lot of implied knowledge. If you don't already have it, the above might be hard going. I hope it helps at least some of you. -- Jonathan

On Mon, Jul 20, 2020 at 03:22 Jonathan Fine wrote:

This is a continuation of my previous post to this thread.

Python's FOR ... ELSE ... , Raymond Hettinger has told us, has origins in some ideas of Don Knuth.

That’s news to me (both that it’s due to Knuth and that Raymond said so). I invented it without awareness of prior art, by reasoning about the similarity between IF and WHILE (FOR followed from WHILE). —Guido -- --Guido (mobile)

I don't know what to do about the zero iterations case, though. Perhaps simply `if not:' Best wishes Rob Cliffe

On 20/07/2020 09:56, Alex Hall wrote:

On Mon, Jul 20, 2020 at 10:36 AM Rob Cliffe via Python-ideas mailto:python-ideas@python.org> wrote:

May I repeat:  Spelling 'if break:' and 'if not break:' rather than say 'on_break:' etc. would avoid adding new keywords.

I don't know what to do about the zero iterations case, though.

It could be that if `break` appears somewhere that an expression is expected, it becomes an expression with the value 0 or 1 (or False or True) to indicate the number of breaks that happened in the previous loop, and similarly some other bit of code involving keywords can become the number of iterations of the previous loop. This could be represented by `for`, `len(for)`, `pass`, etc. So one might write:

``` for x in ...:     ... if not pass:     ... elif pass == 1:     ... else:     ... ``` `break' becoming an expression is fine by me.

But detecting the number of iterations (however it's spelt) might be tricky. Always counting the number of iterations would slow down *every* for/while loop - surely unacceptable. So the compilation process must only incorporate this loop-counting when the loop is followed (after 100 lines of code??) by a reference to the loop count. Another way would be for the first iteration (i.e. the first call of `next') to be coded separately (in the bytecode).  If the first call does not raise StopIteration, it could set a flag meaning "at least 1 iteration occurred",  But this would bloat the code, and again doesn't seem like a great idea if it applies to *every* for/while loop. Therefore: I suggest that the proposal should be modified to just detect break or no break.  That's already progress.  And if in future someone thinks of a brilliant way of detecting zero (or N) iterations,  that can be added later.

On 21 Jul 2020, at 18:47, Rob Cliffe via Python-ideas wrote:

 On Mon, Jul 20, 2020 at 03:22 Jonathan Fine wrote:

...

This is a continuation of my previous post to this thread.

Python's FOR ... ELSE ... , Raymond Hettinger has told us, has origins in some ideas of Don Knuth.

That’s news to me (both that it’s due to Knuth and that Raymond said so). I invented it without awareness of prior art, by reasoning about the similarity between IF and WHILE (FOR followed from WHILE).

—Guido

See Raymond's video "Transforming Code into Beautiful, Idiomatic Python" at https://www.youtube.com/watch?v=OSGv2VnC0go from 15 min 50 sec to 18 min 57 sec.

On 20/07/2020 15:42, Guido van Rossum wrote:

...

Also, let me be clear that this feature will never be added to the language.

With respect, that seems pretty dogmatic, given that for...else is one of the most confusing features of Python. What would be so terrible about allowing, at minimum, `if not break:' as a synonym for 'else:'?

1. Because that not what else mean today. Its elif never looped. 2. Because if after for is confusing. I can get behind elif as after for it pull work. Barry

Best wishes Rob Cliffe _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4H5SMU... Code of Conduct: http://python.org/psf/codeofconduct/

On 2020-07-22 00:02, Rob Cliffe via Python-ideas wrote:

...

...

On 21 Jul 2020, at 18:47, Rob Cliffe via Python-ideas wrote:  On Mon, Jul 20, 2020 at 03:22 Jonathan Fine mailto:jfine2358@gmail.com> wrote:

This is a continuation of my previous post to this thread.

Python's FOR ... ELSE ... , Raymond Hettinger has told us, has origins in some ideas of Don Knuth.

That’s news to me (both that it’s due to Knuth and that Raymond said so). I invented it without awareness of prior art, by reasoning about the similarity between IF and WHILE (FOR followed from WHILE).

—Guido

See Raymond's video "Transforming Code into Beautiful, Idiomatic Python" at https://www.youtube.com/watch?v=OSGv2VnC0go from 15 min 50 sec to 18 min 57 sec.

On 20/07/2020 15:42, Guido van Rossum wrote:

...

Also, let me be clear that this feature will never be added to the language.

With respect, that seems pretty dogmatic, given that for...else is one of the most confusing features of Python. What would be so terrible about allowing, at minimum, `if not break:' as a synonym for 'else:'?

1. Because that not what else mean today. Its elif never looped. 2. Because if after for is confusing. I can get behind elif as after for it  pull work. I'm sorry, of the above two points I don't understand 1. at all, and I only half understand 2.  Please could you rephrase more clearly for an idiot like me.:-) But as to `if` after `for` being confusing, are you seriously saying

On 21/07/2020 22:07, Barry wrote: that `else` after `for` is *less* confusing?

...

'if' introduces a statement structure, 'else' doesn't. Having 'if' sometimes continue a statement structure (a loop) would be more confusing.

The current rule: 'else' continues the 'if' or loop structure. The new rule: 'if' continues a preceding loop structure if it's followed by 'break', else it's the start of an 'if' structure. Which rule is simpler?

On 22/07/2020 00:29, MRAB wrote:

On 2020-07-22 00:02, Rob Cliffe via Python-ideas wrote:

...

...

...

On 21 Jul 2020, at 18:47, Rob Cliffe via Python-ideas wrote:  On Mon, Jul 20, 2020 at 03:22 Jonathan Fine mailto:jfine2358@gmail.com> wrote:

    This is a continuation of my previous post to this thread.

    Python's FOR ... ELSE ... , Raymond Hettinger has told us, has     origins in some ideas of Don Knuth.

That’s news to me (both that it’s due to Knuth and that Raymond said so). I invented it without awareness of prior art, by reasoning about the similarity between IF and WHILE (FOR followed from WHILE).

—Guido

See Raymond's video "Transforming Code into Beautiful, Idiomatic Python" at https://www.youtube.com/watch?v=OSGv2VnC0go from 15 min 50 sec to 18 min 57 sec.

On 20/07/2020 15:42, Guido van Rossum wrote:

...

Also, let me be clear that this feature will never be added to the language.

With respect, that seems pretty dogmatic, given that for...else is one of the most confusing features of Python. What would be so terrible about allowing, at minimum, `if not break:' as a synonym for 'else:'?

1. Because that not what else mean today. Its elif never looped. 2. Because if after for is confusing. I can get behind elif as after for it  pull work. I'm sorry, of the above two points I don't understand 1. at all, and I only half understand 2.  Please could you rephrase more clearly for an idiot like me.:-) But as to `if` after `for` being confusing, are you seriously saying

On 21/07/2020 22:07, Barry wrote: that `else` after `for` is *less* confusing?

...

'if' introduces a statement structure, 'else' doesn't. Having 'if' sometimes continue a statement structure (a loop) would be more confusing.

The current rule: 'else' continues the 'if' or loop structure.

The new rule: 'if' continues a preceding loop structure if it's followed by 'break', else it's the start of an 'if' structure.

Which rule is simpler? "Simpler" doesn't always equate to "easier to understand". Which is more *intuitive*, for...else or for...if [not] break? And if we allowed for...if [not] break... else   - now there's an example of 'else' after 'for' that anyone could grok. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OCYFEF... Code of Conduct: http://python.org/psf/codeofconduct/

how about: for something in some_iterable: some_stuff_with_maybe_a_break else if not break: something_more No new keywords :-) or: for something in some_iterable: some_stuff_with_maybe_a_break else: # if not break: something_more and no changes needed to Python! I may actually start doing that myself ... As for the "loop didn't run at all" case: Does anyone find a need for that? Personally, I've found that everytime I do some kind of check for an empty iterable before a loop, it was totally unnecessary. A for loop means: "Do this stuff to all the items in this iterable." Most of the time, if there's nothing there, you don't need to do the stuff, and that's that. -CHB On Tue, Jul 21, 2020 at 5:28 PM Ethan Furman wrote:

On 7/20/20 7:34 AM, Barry Scott wrote:

...

To avoid the ambiguity of `if` after `for` why not follow `for` with `elif`?

for x in ...: ...

elif break: # break was called elif not break: # looped at least once and break not used elif pass: # same as else today # loop'ed no times

(I always have to think what else means after a for).

Keep thinking... ;)

`else` today /does not/ mean "loop'ed no times". To copy Steven D'Aprano's example:

...

py> for x in [1,2]: ... print("inside loop") ... else: ... print("elif never looped") ... inside loop inside loop elif never looped

...

Mistaking the semantics for "if never looped" is a very common mistake. Welcome to the club :-)

-- ~Ethan~ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UZFPLN... Code of Conduct: http://python.org/psf/codeofconduct/

-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

Hello, On Tue, 21 Jul 2020 17:48:35 -0700 Christopher Barker wrote:

how about:

for something in some_iterable: some_stuff_with_maybe_a_break else if not break: something_more

No new keywords :-)

or:

for something in some_iterable: some_stuff_with_maybe_a_break else: # if not break: something_more

This is the most genius solution posted to this thread. And if the thread didn't die after van Rossum's post, I don't cheer hopes it would die now, but let me sprinkle in another "fresh" thought. First let me remind how this thread started:

ELSE-clause in FOR and WHILE has unclear syntax. I suggest new clause instead

Then various people started to throw in variants of even more unclear and confusing syntax (like "if" after "for"), with some percentage of those people demonstrating not understanding how the original "else" works. But consider following idea: if it's confusing, DO NOT USE it. You don't hear that often, but: treat Python as a generic programming language, not as a bag of tricks. The fact that most other languages don't have extra clause after "for" is enough of a reason to not use it in Python either. So why it exists at all then? It's there for people who don't find it confusing, for very responsible use. As a random example, after studying 2 (bytecode) Python compilers and having written my own (so I know what code is generated from for-else), I no longer find it confusing. I actually found 2 intuitive ways to use that construct, in the very compiler mentioned - after all, if you eyeball a Python compiler, you either know, or ready to learn, how all language constructs work. For anything else - clear ban. Everyone should consider that too. (But please leave the language syntax alone (backwards compatibility, etc.), at least that's a suggestion which comes out from van Rossum's post).

As for the "loop didn't run at all" case: Does anyone find a need for that? Personally, I've found that everytime I do some kind of check for an empty iterable before a loop, it was totally unnecessary.

I find the need for that regularly. And I use the obvious syntax which everyone else uses: if not seq: print("This page is intentionally left blank") else: for i in seq: ... Any adhoc, confusing syntax someone may imagine to add, would go to the same "DO NOT USE" category. So, I pray to van Rossum's answer that something like that will never be added to the language. (Which is hard to hang hopes on, given all the mess added recently.) [] -- Best regards, Paul mailto:pmiscml@gmail.com

I find the need for that regularly. And I use the obvious syntax which everyone else uses:

if not seq: print("This page is intentionally left blank") else: for i in seq: ...

Not so easy for an iterator though. I’m more likely to do something like this: Page = NewPage() For content in iterable: Page.Add_stuff(content) If not Page: print("This page is intentionally left blank") (Sorry For the non PEP8 compliant capitalization— damn phone) -CHB

--

Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

I'm (weakly) +1 for the concept of for..else being confusing, weird, and somehow not quite suitable/useful for many use-cases where it feels like it should. I'm -1 for each of the suggested improvements that I've understood so far. I agree that the suggested 'ban' on changes in this area is probably not helpful, however it feels like a sloppy way of saying that changes to the syntax are very unlikely to be practical, for a couple of annoying, but important reasons. The: for: ... else: # if not break: ... Solution seems to highlight this. The proposed convention of using comments here is clearly elective (nothing changes if you don't include the comment, although a style checker could require it, which would be a nice way of catching possible indentation errors) Because this is implemented as a comment, and thus optional, it feels pointless because the original confusion is still there for people who don't bother to add the comment, and less experienced coders are less likely to know about the convention. BUT it's probably as good as any other changes because... I don't feel that, on balance, the cost of making a breaking syntax change to the language (having worked on huge python codebases, the cost of any breaking syntax change is just massive) is justified here, so whatever improvements may be made would probably have to still support the old syntax as-is. The moment we retain the old syntax, then the new syntax becomes optional, and we're back in the problems with the comment approach. The only route I can see to a workable outcome here is to implement the: "else if not break:" clause as an optional alternate syntax, and update all the documentation to recommend using the new syntax over the old one (effectively silently deprecate for:...else:... syntax, but retain it indefinitely). But this has issues, because some people will still use the old syntax, so we'll end up with lots of code out there using both variants, and that's as likely to add to the general confusion here as reduce it. Steve On Wed, Jul 22, 2020 at 9:26 AM Mathew Elman wrote:

On Wed, 22 Jul 2020 at 04:47, Paul Sokolovsky wrote:

...

Hello,

On Tue, 21 Jul 2020 17:48:35 -0700 Christopher Barker wrote:

...

how about:

for something in some_iterable: some_stuff_with_maybe_a_break else if not break: something_more

No new keywords :-)

or:

for something in some_iterable: some_stuff_with_maybe_a_break else: # if not break: something_more

This is the most genius solution posted to this thread.

And if the thread didn't die after van Rossum's post, I don't cheer hopes it would die now, but let me sprinkle in another "fresh" thought. First let me remind how this thread started:

...

ELSE-clause in FOR and WHILE has unclear syntax. I suggest new clause instead

Then various people started to throw in variants of even more unclear and confusing syntax (like "if" after "for"), with some percentage of those people demonstrating not understanding how the original "else" works.

But consider following idea: if it's confusing, DO NOT USE it. You don't hear that often, but: treat Python as a generic programming language, not as a bag of tricks. The fact that most other languages don't have extra clause after "for" is enough of a reason to not use it in Python either.

The problem isn't that it is unclear, the problem is that it is misunderstood. If it was unclear what `for...else` means/does then yes, do-not-use would fix the problem. The fact that it can and *is* *mis*understood as doing something else means that people have to learn to not use something that feels like it *should* be usable.

...

So why it exists at all then? It's there for people who don't find it confusing, for very responsible use. As a random example, after studying 2 (bytecode) Python compilers and having written my own (so I know what code is generated from for-else), I no longer find it confusing. I actually found 2 intuitive ways to use that construct, in the very compiler mentioned - after all, if you eyeball a Python compiler, you either know, or ready to learn, how all language constructs work.

For anything else - clear ban. Everyone should consider that too. (But please leave the language syntax alone (backwards compatibility, etc.), at least that's a suggestion which comes out from van Rossum's post).

Frankly, saying that a part of a language that is frequently misunderstood, is *never* allowed to be improved is disappointing when the suggestion that it can be (somehow) has been so well received by everyone else.

...

...

As for the "loop didn't run at all" case: Does anyone find a need for that? Personally, I've found that everytime I do some kind of check for an empty iterable before a loop, it was totally unnecessary.

I find the need for that regularly. And I use the obvious syntax which everyone else uses:

if not seq: print("This page is intentionally left blank") else: for i in seq: ...

Any adhoc, confusing syntax someone may imagine to add, would go to the same "DO NOT USE" category. So, I pray to van Rossum's answer that something like that will never be added to the language. (Which is hard to hang hopes on, given all the mess added recently.)

Many people offering approaches is not muddling the thread. Clearly, most people here agree that `for...else` is confusing/unintuitive on it's own, and could be improved (not removed, but improved). The discussion was trying to find an improvement that people agree on as well. The reason there are so many offerings, is probably because everyone has had a similar thought about it in the past.

Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.

If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.

References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VLKG6N... Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, Jul 21, 2020 at 05:48:35PM -0700, Christopher Barker wrote:

for something in some_iterable: some_stuff_with_maybe_a_break else: # if not break: something_more

and no changes needed to Python!

I may actually start doing that myself ...

I always do that, not because I need it now, but because the next person who reads my code in six months might need it. That person might even be me.

As for the "loop didn't run at all" case: Does anyone find a need for that? Personally, I've found that everytime I do some kind of check for an empty iterable before a loop, it was totally unnecessary.

If we had it, I would use it. It is generally possible to work around the lack, e.g. with an explicit test of a sequence (but that doesn't work with iterators), but I find that sometimes it isn't *obvious* that the empty loop case is handled correctly: for x in iterable: do stuff continue processing If iterable is empty, is the code still correct? Sometimes that's obvious, but when it *isn't* obvious I wish there was a way to run this: for x in iterable: do stuff if loop was empty: whatever is needed to make it obviously correct such as an assert, or early return I'd rather have an extra couple of lines of code and obviously correct code than save a few lines and have to think hard about whether the code is correct :-) More rarely I do need to treat the empty case specially. If the iterator is a sequence I can test the length up front, but this doesn't work with iterables. It's not *hard* to work around this, it's just inelegant. -- Steven

Hello, On Wed, 22 Jul 2020 20:00:29 +1000 Steven D'Aprano wrote: []

...

...

py> for x in [1,2]: ... print("inside loop") ... else: ... print("elif never looped") ... inside loop inside loop elif never looped

This is why I have long-argued that the keyword here should be *then* not else. The semantics are that the loop executes, *then* the following "else" block executes,

But no, loop executes, *or else* the following "else" block executes ;-). That's the logic of founding fathers. After one grasped that logic, one comes to appreciate a weird beauty of it. The verdict remains the same though: "Do Not Use".

I am confused. I don't understand your comment.

Your "But no" suggests to me that you are disagreeing with me. Your comment "loop executes *or else* ..." suggests that you are denying the evidence of the code, and defending the idea that either the loop runs, or the else clause runs, but not both.

You literally say that the loop runs, *or else* (xor) the else block runs.

Nope, I'm not saying that. I'm saying that if loop can run, it runs. Else if it can't run (which happens when it's exhausted), then "else" runs. The only unclear thing here is that "break" skips it. That's not immediately obvious, but if you think about, it starts to make sense, because otherwise no "else:" would be needed at all. And I'm saying that not in justification of "else:", but as an example of learning how to understand what made the language author chose "else:" as the name of that clause. The above aren't my words either, that's what I read to grasp that stuff (and it stuck only when I peered thru enough bytecode). If there is any obvious conclusion to make from all that, that would be the same "Do Not Use" already mentioned. On the topic of "change something", I'd personally wouldn't find it a tragedy if: --- for ...: elif not break: --- was made a synonym of --- for ...: else: --- But I'm worried about the usual scope creep in the discussion here, with all the further "if break/if empty/if not empty" adhoc clauses. And I find "else: # if not break" to be pretty neat already, just need to crusade to make linters require it by default, as a second choice after unconditionally warn on using "else:" in the first place. Note that you'll need to make linter-crusade even if "elif not break:" is adopted, because "else:" stays put, for backward compatibility. -- Best regards, Paul mailto:pmiscml@gmail.com

On Wed, 22 Jul 2020 at 13:18, Mathew Elman wrote:

...

Ones that retain else on loops are bad because they end up providing two (typically equally confusing) ways of doing things.

I don't think this is the case. I agree that adding an alternative to `else` just to have an alternative is not a good fix, but adding explicit ways to refer to when breaking from the loop would make the use of `else` as it already is clearer.

For example, breaking the change into 2 parts: 1. Adding `elif` to the `for...else` and `while...else` statements seems a logical extension. Guido has even said that the else in loops was invented by reasoning the connection of `if` to `while` (and then `while` to `for`). Perhaps this should be in its own discussion so as not to clutter this thread?

IMO, allowing for ... elif x == 2: do something to mean "if we didn't break out of the loop, and x is 2" would be really confusing. And to have the elif after a loop be limited to a different set of conditions than "ordinary" elif would *also* be really confusing.

2. Adding a way to use this new `elif` to check the state of the loop. Possibly including if it was broken out of or if it was never entered. Such as having special local variables that are only defined in the block/frame of the loop.

Same logic here - if we allow "elif not break" (for example), it would be really confusing to *arbitrarily* only allow that if the elif is attached to a loop. So we need to define what if x == 2: do something elif not break: what? means in general code. And that means inventing rules for the scope of "break as an expression". And in a similar vein, what does it mean to pass "break" to a function? def invert(flag): return not flag for ... elif invert(break): ... It's not that any of these things are *reasonable* to do, it's that all the special cases needed to disallow them would be confusing, and if we *didn't* disallow them, all of the rules needed to give them meaning in (conceded) unreasonable places would be confusing. The trick here is *not* to look at the case that you expect the construct to be used in - obviously it'll look good to you in that context, if you like the idea at all. What you need to look at is all the other ways it could be applied, and verify that the costs justify the improvement that you saw when you first encountered the idea. Paul

Hello, Why not just use Raymond's suggestion nobreak as a replacement of the else in loops and deprecate the else in Python 4? There is at least a precedent when not equal <> was deprecated in favor of != from Py2 to Py3. We could do the same with else/nobreak between Py3 and Py4. João Matos On 22/07/2020 14:36, Mathew Elman wrote:

On Wed, 22 Jul 2020 at 13:45, Paul Moore mailto:p.f.moore@gmail.com> wrote:

On Wed, 22 Jul 2020 at 13:18, Mathew Elman mailto:mathew.elman@ocado.com> wrote: >> Ones that retain else on loops are bad because >> they end up providing two (typically equally confusing) ways of doing >> things. > > I don't think this is the case. I agree that adding an alternative to `else` just to have an alternative is not a good fix, but adding explicit ways to refer to when breaking from the loop would make the use of `else` as it already is clearer. > > For example, breaking the change into 2 parts: > 1. Adding `elif` to the `for...else` and `while...else` statements seems a logical extension. Guido has even said that the else in loops was invented by reasoning the connection of `if` to `while` (and then `while` to `for`). Perhaps this should be in its own discussion so as not to clutter this thread?

IMO, allowing

    for ...     elif x == 2:         do something

to mean "if we didn't break out of the loop, and x is 2" would be really confusing.

I don't think this would be any more confusing than `for...else` already is, and `while...elif...else` still seems like a logical extension of `while...else`.

x=0 while x < 10:     delta = get_delta(x)     if delta == 0:         break     x += delta elif x%2:     print(f"{x} is odd and > 10") else:     print(f"{x} is even and > 10")

And to have the elif after a loop be limited to a different set of conditions than "ordinary" elif would *also* be really confusing.

Absolutely! I would not suggest limiting it to any special cases. Hence why I split up the change. Adding a way to /also/ use the elif to check the state of the loop is a separate discussion. Be that by using `break` as a special boolean or some other way.

> 2. Adding a way to use this new `elif` to check the state of the loop. Possibly including if it was broken out of or if it was never entered. Such as having special local variables that are only defined in the block/frame of the loop.

Same logic here - if we allow "elif not break" (for example), it would be really confusing to *arbitrarily* only allow that if the elif is attached to a loop. So we need to define what

    if x == 2:         do something     elif not break:         what?

means in general code. And that means inventing rules for the scope of "break as an expression".

And in a similar vein, what does it mean to pass "break" to a function?

    def invert(flag):         return not flag

    for         ...     elif invert(break):         ...

That is fair enough, like I have said I am not attached (though others may be) to the idea of using `break` as a special boolean. Would it be more feasible to have a variable that persists beyond the scope of the loop and is not `break` but something else? For example, and this is not 100% serious but something like : `iter.broken`, `iter.enetered` etc.

It's not that any of these things are *reasonable* to do, it's that all the special cases needed to disallow them would be confusing, and if we *didn't* disallow them, all of the rules needed to give them meaning in (conceded) unreasonable places would be confusing.

The trick here is *not* to look at the case that you expect the construct to be used in - obviously it'll look good to you in that context, if you like the idea at all. What you need to look at is all the other ways it could be applied, and verify that the costs justify the improvement that you saw when you first encountered the idea.

Good point, I think this is a well made argument for *not* making `break` have a second meaning.

Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.

If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.

References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2XU5PS... Code of Conduct: http://python.org/psf/codeofconduct/

Hello, Maybe I didn't explain it correctly. What I meant was to do exactly the same that happened with <>/!=. That is, add nobreak in Py3 (allowing the use of both else/nobreak) and only deprecate else in Py4. João Matos On 22/07/2020 22:22, Chris Angelico wrote:

On Thu, Jul 23, 2020 at 7:06 AM João Matos wrote:

...

Hello,

Why not just use Raymond's suggestion nobreak as a replacement of the else in loops and deprecate the else in Python 4? There is at least a precedent when not equal <> was deprecated in favor of != from Py2 to Py3. We could do the same with else/nobreak between Py3 and Py4. Py2 supported both <> and !=, so code could be completely compatible with both branches just by using !=. You're proposing creating a new way of doing things and then deprecating or removing one of them, which either means there'll be two identical spellings, or you break everyone's code (or both). It's almost the opposite of the <> change.

Please, everyone, can we NOT keep coming up with ideas that are basically "let's invent a new spelling for exactly the same thing, with no benefits, and demanding new keywords, so we can break people's code for no reason"? You can always just write your own transpiler to let yourself spell it your preferred way.

ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GSBEBZ... Code of Conduct: http://python.org/psf/codeofconduct/

Steven D'Aprano writes:

On Wed, Jul 22, 2020 at 06:14:39AM +0300, Paul Sokolovsky wrote:

...

But no, loop executes, *or else* the following "else" block executes ;-).

He means the loop *suite* executes (this includes "getting to" a break statement or other control flow that leaves the loop *statement* entirely), and if it doesn't, the else suite does. This is "why" such nonlocal exits differ from finally in that they don't run the else suite. I personally think this is a perfectly clear and convincing argument for "else" as the keyword for this statement (once "suite" is added to Paul's phrasing). This is why programmers should major in English, and do a graduate degree in programming if they really think they need a degree in programming.

You literally say that the loop runs, *or else* (xor) the else block runs. But you say this in response to a demonstration that the loop runs, *and* the else block runs.

You mean "the part of the loop *statement* that starts with 'for' or 'while'" runs, but this is somewhat inconsistent as the else suite is also part of the loop statement. I don't know of a concise but explicit way to express what you mean, although I understood it perfectly well.

On 23/07/2020 16:24, Stephen J. Turnbull wrote:

Steven D'Aprano writes:

...

On Wed, Jul 22, 2020 at 06:14:39AM +0300, Paul Sokolovsky wrote:

...

...

But no, loop executes, *or else* the following "else" block executes ;-).

He means the loop *suite* executes (this includes "getting to" a break statement or other control flow that leaves the loop *statement* entirely), and if it doesn't, the else suite does. This is "why" such nonlocal exits differ from finally in that they don't run the else suite.

I personally think this is a perfectly clear and convincing argument for "else" as the keyword for this statement (once "suite" is added to Paul's phrasing).

This is why programmers should major in English, and do a graduate degree in programming if they really think they need a degree in programming.

The upholders of the status quo regularly provide gallant explanations of why "else" is perfectly natural, even intuitive. The fact is, it isn't.  If it were, it wouldn't **need** to be repeatedly explained by gurus to lesser mortals.  I can't think of any other area of Python that needs to be defended so regularly and so vociferously, nor that very experienced Python programmers confess they find confusing.  Swelp me, someone in this very thread (Barry) misunderstood it[1].  And suggesting that those of us who don't find it clear lack skill in English is just plain insulting. YMMV, but the only way I can grok it when I see it is to mentally translate "else" to "if no break".  This is mental effort that would be spared or at least diminished if it were spelt in a more obvious way in the first place. Best wishes Rob Cliffe [1] or at least I think he did, I had trouble understanding him.

On Fri, 24 Jul 2020 at 02:18, Rob Cliffe via Python-ideas wrote:

The upholders of the status quo regularly provide gallant explanations of why "else" is perfectly natural, even intuitive. The fact is, it isn't. If it were, it wouldn't *need* to be repeatedly explained by gurus to lesser mortals.

Fair point. It needs to be learned and remembered. It's not intuitive.

YMMV, but the only way I can grok it when I see it is to mentally translate "else" to "if no break". This is mental effort that would be spared or at least diminished if it were spelt in a more obvious way in the first place.

Again, probably true. With hindsight, if we were designing Python from scratch now, we'd probably not spell this as "else". We'd probably omit it altogether rather than using an alternative spelling, but that's a side issue. BUT - we're not designing Python now. The "else" clause on loops has been around for many years. It's in books, training courses and in existing, working code. We can't break all of that without a fairly large cost. And (as I've noted before) having *two* ways of writing this obscure construct would be even more confusing, particularly as people working with existing code or learning from existing training materials will naturally see the (presumably less intuitive and obvious) "else" spelling. So even accepting all of your points above, it's still very unlikely this will change. Not because there's no benefit, but because the cost is too high. Paul

On Thu, 23 Jul 2020 at 16:25, Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:

Mathew Elman writes:

...

Frankly, saying that a part of a language that is frequently misunderstood, is *never* allowed to be improved is disappointing when the suggestion that it can be (somehow) has been so well received by everyone else.

The highly improbable is frequently well-received.

What can surely be improved is the documentation, specifically the Tutorial. Something like

The else clause of a loop statement has frequently been misunderstood. In a for or while loop *statement*, on each iteration, the condition is tested and exactly one of the following occurs:

1. If truthy, the loop *suite* runs to completion and the test is repeated for the next iteration, 2. OR the loop *suite* runs and there is a nonlocal exit such as return or break or raise, which exits the statement as well. 3. OTHERWISE the condition is false, and the else suite, if any, runs, then the statement is exited.

The emphasis is for contrast in this discussion. The Language Reference already says precisely this, although much more concisely.

I don't expect supporters of "elif not break" etc to think this is sufficient, and supporters of the Else Ban similarly. Please consider if this is helps clarify the Tutorial, and if it doesn't get booed into oblivion, I'll work up a patch (I think that the section on control flow would benefit from some reorganization as well, "just stick it in somewhere" is not what I have in mind :-).

Credit where credit is due, I think this is definitely an improvement. It does make it require slightly less meticulous reading to understand `else`. However, I still think that there is value in improving the `for...else` and `while...else` intuitiveness, if it can be done at an acceptable cost. (As is the case with any change) IMO the solution is not to change `else` but to add an additional with the opposite meaning that makes the use of `else` with `for` and `while` more intuitive, such as adding `elif`, which feels natural, and a special boolean, which perhaps doesn't. Or adding `except` for catching raised Exceptions rather than breaks, which makes `else` clearly behave how it does for `try`. Or another solution that achieves the additional clarity *without* removing/changing else itself.

Steve

-- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

On Sat, Jul 25, 2020 at 11:13 AM Steven D'Aprano wrote:

On Thu, Jul 23, 2020 at 07:22:51AM +1000, Chris Angelico wrote:

...

Please, everyone, can we NOT keep coming up with ideas that are basically "let's invent a new spelling for exactly the same thing, with no benefits,

Surely having a less confusing and misleading spelling is a benefit.

Minor, given that the existing spelling still has to be supported. Now you have two ways to do it, for the foreseeable future, and only style guides will differentiate. And a lot of style guides will say "prefer else because it's compatible with more Python versions". How long will it be before you can actually take advantage of it?

We like to use Python because its syntax is so readable and obvious. "for...else" is a wart on the language, it is a lovely feature marred by a confusing keyword. The long term benefit is to reduce that confusion.

I don't dispute that, but that's very long term benefit, with a lot of short and medium term costs. The concept is a bit unusual (I don't know many other languages that support this with *any* spelling), so it still has to be explained, and a lot of people will still be confused no matter how you spell it. How much benefit do you actually gain?

Guido seems to be open to the use of *soft keywords* now that CPython has moved to a PEG parser. Perhaps we could introduce a soft keyword as an alternative spelling for "else":

for x in sequence: ... then: # allow the bike-shedding to begin :-( ...

Being a soft keyword, outside of that context it will remain legal, so no-one needs to rename their "then" methods or variables.

That's a notable reduction in cost (and an improvement in flexibility for the bikeshedding - although that will, of course, mean that the bikeshedding takes ten times longer!), but the cost of creating a second way to do things isn't just the creation of the keyword.

So here's a concrete proposal:

(1) `for...else` and `while...else` stay, for backwards compatibility.

(2) Add a soft keyword "then" (bikeshed away...) to use in for and while loops, as an alternative preferred spelling to "else".

(3) Update PEP 8 to make it clear that new code should use `for...then` and `while...then` rather than "else". (Old code need not change just for the sake of changing it.)

(4) Linters and style-checkers can prefer `then`, but the interpreter itself will remain neutral and accept both.

To avoid all doubt:

(5) There is no plan to depreciate the hard keyword `else`, not even a PendingDepreciation warning.

Linters and style checkers will have to choose whether to recommend the "better" spelling (unquantifiable benefit) or the one that runs on more versions of Python (concrete, meaningful benefit).

(6) Any suggestion that we repurpose `for...else` to mean "run this if the loop is empty" will have to justify itself. It is not part of this proposal.

I hope nobody EVER proposes that. Having code that means different things on different Python versions would be an absolute pest to work with. But if all the prior objections are overcome and "for... then" gains currency, there'd be some reasonable grounds for proposing a completely different keyword to have the "if loop is empty" semantics.

It seems to me that this is a pretty minor change, with little downside, that could have a big effect on the readability and usefulness of what's currently spelled as `for...else` and underused because people find it confusing. Compared to the benefits, the downsides are small:

- Someone has to do the work. That's a one-off cost.

- Double the tests: we have to verify `for...else` and `for...then` both work. This is a pretty small cost.

- Two ways to do it. Despite the Zen, there are two ways to do many things in Python. But this is a pure alias: for...then and for...else are literally compiled to the same code. The Zen should be understood as *food for thought* not unbreakable rules of nature. If we accept this proposal, we could interpret it as follows:

* the One Way to do it is `for...then`;

* but for backwards compatibility there's also an alternative spelling that we prefer not to talk about, see the docs if you care.

And all your documentation, examples, etc, have to care.

...

and demanding new keywords, so we can break people's code for no reason"? You can always just write your own transpiler to let yourself spell it your preferred way.

How do I do that?

That's not a rhetorical question. I keep wanting to study projects like LikePython for hints, because I am sick of *Old Man Python* telling me what I can and can't write, but somehow never find the time.

It depends how smart you want it to be. If you literally just search and replace "then:" into "else:" without caring about context, it'd be trivially easy. Obviously that's pretty risky, but adding a check for string literals would probably cover most normal code. Actually doing the job properly...

If we had some sort of easy to use standard library support for transpiling code, then your advice could actually be practical and not just dismissive. "Pft, if you don't like it, write your own language" is not exactly practical for most people. Even if a transpiler is a tad simpler than writing an entire interpreter or compiler, it's still a new language.

... would be best done with stdlib support, yes. I think import hooks can do everything that's needed, but I've never actually done it. Normally I'd just use a simple source-to-source transformation before execution, and usually I do things that aren't ever going to show up (string literals aside), so I don't need it to be very smart. ChrisA

On Sat, Jul 25, 2020 at 12:09 PM André Roberge wrote:

On Fri, Jul 24, 2020 at 10:43 PM Chris Angelico wrote: SNIP

...

...

If we had some sort of easy to use standard library support for transpiling code, then your advice could actually be practical and not just dismissive. "Pft, if you don't like it, write your own language" is not exactly practical for most people. Even if a transpiler is a tad simpler than writing an entire interpreter or compiler, it's still a new language.

... would be best done with stdlib support, yes. I think import hooks can do everything that's needed, but I've never actually done it. Normally I'd just use a simple source-to-source transformation before execution, and usually I do things that aren't ever going to show up (string literals aside), so I don't need it to be very smart.

Already done (with a different keyword):

https://aroberge.github.io/ideas/docs/html/nobreak.html

Thank you. Especially since the source code is extremely short: https://github.com/aroberge/ideas/blob/master/ideas/examples/nobreak.py I'd like to see this 'ideas' module (or similar) better known. It'd help a lot with complaints like Steven's. ChrisA

On 25/07/2020 07:59, David Mertz wrote:

On Thu, Jul 23, 2020, 9:19 PM Rob Cliffe via Python-ideas

The upholders of the status quo regularly provide gallant explanations of why "else" is perfectly natural, even intuitive.

They remind me of these two mathematicians: M1: This result is trivial. M2: No it isn't. M1: Yes it is. M2: Well, I don't see it. M1: Sure it's trivial.  Look ...     ...     [They discuss it for about an hour]     ... M2: You're right, it *is* trivial!

On Sat, Jul 25, 2020 at 11:40:06AM +1000, Chris Angelico wrote:

And a lot of style guides will say "prefer else because it's compatible with more Python versions".

Like they did in Python 2 when we had two ways of getting the next element from an iterator? # Python 2.7 py> it = iter([1, 2]) py> next(it) 1 py> it.next() 2 How many style guides said "Prefer the next *method*, because more Python versions (Python 2.2 on up) support it"? If there were any at all, they were a microscopic proportion of the ones that used the preferred next *function*, because that's what the std lib and documentation said to use. If the docs and PEP 8 says the soft-keyword "then" is preferred, the number of people who will stick to the "else" keyword a single day longer than they need to for backwards compatibility will rapidly drop to zero.

How long will it be before you can actually take advantage of it?

Of course libraries that need to support older versions of the language will have to use the old form, but that applies to *every* new feature. How many libraries that support Python 3.3 or 3.5 are using the walrus operator? Zero. Therefore we shouldn't have added the walrus operator, right? As the author of the walrus PEP, I'm sure you recognise that this sort of argument is weak. When we add new syntactic features we're looking forward to the future. Not everyone can be an early adopter using the cutting edge version with the latest features, but on the other hand most people aren't stuck forever supporting Python 3.3 (or 1.5) either. Some people will be able to use it the moment the feature is checked into the source repo. Some people won't be able to use it until 2040. And the majority will start to use it within a year or two. Like any other new language feature. [...]

And all your documentation, examples, etc, have to care.

Of course there will be a transition period where people say "I tried to run for...then and got a syntax error", but that doesn't last forever. When is the last time you've seen someone asking about syntax errors from `with` statements? Or async and await, for a more recent addition to the language? Look at PEP 530: https://www.python.org/dev/peps/pep-0530/ This PEP added a second way to do it: # Old Way, necessary before 3.6 result = [] async for i in aiter(): if i % 2: result.append(i) # New Way, only valid from 3.6 onwards result = [i async for i in aiter() if i % 2] If I were to go to StackOverflow, or Python-List, and ask "How do I run a list comprehension asyncronously?" how many people would give the Old Way? Would you? Of course the official docs have to document that "for...else" is accepted by the compiler and translated into "for...then", for backwards compatibility; and old documentation won't change. But new documentation would rapidly change to preferring the new version and not even mentioning the old version except maybe as a curio of the language. Who remembers using the Decorate-Sort-Undecorate idiom in Python? It was *everywhere*. Then we got a key function parameter, and seemingly overnight the DSU idiom just disappeared. -- Steven

On Sat, Jul 25, 2020 at 7:18 PM Steven D'Aprano wrote:

On Sat, Jul 25, 2020 at 11:40:06AM +1000, Chris Angelico wrote:

...

And a lot of style guides will say "prefer else because it's compatible with more Python versions".

Like they did in Python 2 when we had two ways of getting the next element from an iterator?

# Python 2.7 py> it = iter([1, 2]) py> next(it) 1 py> it.next() 2

How many style guides said "Prefer the next *method*, because more Python versions (Python 2.2 on up) support it"?

I've no idea. When did the next() function come in, and what was it like while older versions than it were still current? Looking *now* isn't indicative.

...

How long will it be before you can actually take advantage of it?

Of course libraries that need to support older versions of the language will have to use the old form, but that applies to *every* new feature. How many libraries that support Python 3.3 or 3.5 are using the walrus operator? Zero. Therefore we shouldn't have added the walrus operator, right?

As the author of the walrus PEP, I'm sure you recognise that this sort of argument is weak. When we add new syntactic features we're looking forward to the future. Not everyone can be an early adopter using the cutting edge version with the latest features, but on the other hand most people aren't stuck forever supporting Python 3.3 (or 1.5) either.

Of course, but it IS an argument. The walrus operator gives new expressiveness. Async/await has a massive advantage over manually doing your wait points. The "but you can't use it yet" argument is a lot weaker than "it makes your code way cleaner", but the argument in favour of the current proposal is "it's a better choice of words". I don't dispute that it would be an improvement. I just dispute that it's enough of an improvement to create a new spelling for something that has no other advantage. Do you REALLY think that everyone will automatically understand it just because it's spelled "for... then" instead of "for... else"? ChrisA

On Sat, Jul 25, 2020 at 4:39 AM Eric V. Smith wrote:

On 7/25/2020 7:28 AM, Chris Angelico wrote:

...

Do you REALLY think that everyone will automatically understand it just because it's spelled "for... then" instead of "for... else"?

I wouldn't find "for ... then" any less confusing than "for ... else". I do find "for ... else if not break" easier to understand,

I'm pretty sure that the OP on this proposed "then" as a placeholder, with the final choice of word to be determined. But I do think this is pretty darn illustrative --'cause I would find "then" even LESS intuitive, and it's a whole new keyword to boot! I'm one of those folks that have been around Python for a long time -- starting with 1.5 -- and I still find for-else a bit confusing, but I remember that it exists, so go figure it out when I need it. And that is not very often. Frankly, it's a nifty feature, but it's still not a very common use case -- so It's just not a very clear win to spell it better. And as the "then" example shows, it's really hard to find a better spelling -- it's just not that common a construct in programming languages, and it's not used that often in Python -- if it were, I"d probably remember what it meant :-)

but I'm not convinced its worth the hassle over "for ... else # if not break". Four keywords in a row!

well, there are two sides to usability: 1) Remembering it's there, and how to use it when you are writing code, which I think is not such a big deal -- if you remember its there, you can figure out how to use it. And if you don't remember it's there, then a better spelling isn't going to help. 2) understanding what it means when you are reading code -- and that, a better spelling would help with. But I don't get folks that would reject it in a code review -- I'd just suggest that you add a # if not break comment -- or better yet a comment that describes why it's there in the context of that problem -- as comments are supposed to do. Would you really as someone to replace: for dodad in all_the_things: if dodad == something_special: found_special_dodad = True break do_things_with(dodad) else: # the special one wasn't there -- need to process the stuff process(stuff) with this?: found_special_dodad = False for dodad in all_the_things: if dodad == something_special: found_special_dodad = True break do_things_with(dodad) ... if not found_special_dodad: # the special one wasn't there -- need to process the stuff process(stuff) The for--else construct exists for a reason: it's much cleaner than creating a flag and checking it later. Sure it would be nicer if it had a better spelling, but else # not break is pretty easy if you want to make your code more readable and there isn't need for an explanatory comment otherwise. I'm not advocating for any change (Obviously :-) ) -- but if there were to be one, I"d strongly vote for some version of else not break or else if not break because it introduces no keywords, and it's a lot more compatible documentation-wise than a different word -- it's almost like a built-in commnet :-) By that I mean that folks that see the two different spellings in two different tutorials or SO answers ,or whatever, are more likely to realize that they mean the same thing. But all of these always make me wonder about a return inside the suite.

Does the "else" part execute (answer: no). So as a rule, I avoid the construct entirely,

really? does an if-else clause execute if there's a return in the if? no. why would this be any more confusing?

not that it comes up very often, anyway.

This is the really key point. I wanted to use a real code example above, but I could not remember when I'd ever used it -- and it's hard to search for, so I couldn't find one. So: churn to make something rarely needed a little bit better -- I don't see the point. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

How about we just document the whole feature as deprecated and never speak of it again? -- Greg

On 7/25/2020 3:11 PM, Christopher Barker wrote:

On Sat, Jul 25, 2020 at 4:39 AM Eric V. Smith mailto:eric@trueblade.com> wrote:

But all of these always make me wonder about a return inside the suite. Does the "else" part execute (answer: no). So as a rule, I avoid the construct entirely,

really? does an if-else clause execute if there's a return in the if? no. why would this be any more confusing?

Because I always remember "for ... else" has something to do with leaving the loop early, but I don't recall if it's more like try ... finally, or if it's related to the loop exiting early, or the loop not exiting early, or something else I can't recall. So, the answer to your "really?" question is "yes". Eric