This is more of a python-ideas discussion, and Steven's answer is good. I'll just add one thing. Maybe it's obvious to others, but I've liked for...else since I found a kind of mnemonic to help me remember when the "else" part happens: I think of it not as "for ... else" but as "break ... else" -- saying it this way makes it clear to me that the break goes with the else. "If this condition inside the loop is true, break. ... *else* if we didn't break, do this other thing after the loop." -Ben On Mon, Jul 24, 2017 at 12:14 PM, Steven D'Aprano wrote:

Hello Kiuhnm, and welcome.

On Mon, Jul 24, 2017 at 05:35:03PM +0200, Kiuhnm via Python-Dev wrote:

...

Hello,

I think that the expression "for...else" or "while...else" is completely counter-intuitive.

You may be right -- this has been discussed many, many times before. In my personal opinion, the best (and only accurate!) phrase would have been:

for item in sequence: # block then: # block

If you look at the byte-code generated by a for...else statement, you see that the "else" block is unconditionally executed after the for loop completes, unless something causes a jump outside of the entire statement: return, break, or raise. So it is more like:

- run the loop; - *then* run the following block

rather than:

- run the loop; - otherwise ("else") run the following block.

Others disagree and would prefer other keywords. But regardless, backwards compatibility means that we must keep "for...else", so I'm afraid that discussing alternatives is *almost certainly* a waste of time.

...

Wouldn't it be possible to make it clearer? Maybe something like

At this point, no, it is not practical to change the syntax used. Maybe when Python 3.0 was first introduced, but that ship has long sailed. It is very, very unlikely that the syntax for this will ever change, but if it does, it probably won't be until something in the distant future like Python 5.

But not Python 4: Guido has already ruled that Python 4 will not include major backwards-incompatible changes. Going from 3 to 4 will not be as disruptive as going from 2 to 3.

So depending on how you look at it: discussing alternative syntax to for...else is either ten years too late or ten years too early.

-- Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ benhoyt%40gmail.com

On 25 July 2017 at 02:23, Ben Hoyt wrote:

This is more of a python-ideas discussion, and Steven's answer is good.

I'll just add one thing. Maybe it's obvious to others, but I've liked for...else since I found a kind of mnemonic to help me remember when the "else" part happens: I think of it not as "for ... else" but as "break ... else" -- saying it this way makes it clear to me that the break goes with the else. "If this condition inside the loop is true, break. ... *else* if we didn't break, do this other thing after the loop."

For folks looking for a more in-depth explanation of the "if-break-else" approach to thinking about this construct: http://python-notes.curiousefficiency.org/en/latest/python_concepts/break_el... That article also has a note explaining that we're unlikely to ever change this: http://python-notes.curiousefficiency.org/en/latest/python_concepts/break_el... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Mon, Jul 24, 2017 at 7:14 PM, Steven D'Aprano wrote:

Hello Kiuhnm, and welcome.

On Mon, Jul 24, 2017 at 05:35:03PM +0200, Kiuhnm via Python-Dev wrote:

...

Hello,

I think that the expression "for...else" or "while...else" is completely counter-intuitive.

You may be right -- this has been discussed many, many times before. In my personal opinion, the best (and only accurate!) phrase would have been:

for item in sequence: # block then: # block

​IMO, for item in sequence: # block nobreak: # or perhaps `if not break:` # block would be clearer (if the syntax is necessary at all). ​[...]

​

...

Wouldn't it be possible to make it clearer? Maybe something like

At this point, no, it is not practical to change the syntax used. Maybe when Python 3.0 was first introduced, but that ship has long sailed. It is very, very unlikely that the syntax for this will ever change, but if it does, it probably won't be until something in the distant future like Python 5.

​I don't have a strong opinion on this particular case, but if something like this is changed in Python 5, I think the decision should be made much earlier (now?) so that the old else syntax could be discouraged (and new syntax potentially already introduced). The same thing would apply to many other "possibly in Python 5" changes, where there is no reason to expect that the situation is somehow different years later. -- Koos

But not Python 4: Guido has already ruled that Python 4 will not include major backwards-incompatible changes. Going from 3 to 4 will not be as disruptive as going from 2 to 3.

​[...]​ -- + Koos Zevenhoven + http://twitter.com/k7hoven +

On Jul 27, 2017 02:38, "MRAB" wrote: On 2017-07-26 23:55, Koos Zevenhoven wrote:

​IMO,

for item in sequence: # block nobreak: # or perhaps `if not break:` # block

would be clearer (if the syntax is necessary at all).

You couldn't have "if not break:" because that would look like the start of an 'if' statement. Do you mean as an implementation issue or for human readability? "nobreak" would introduce a new keyword, but "not break" wouldn't. Sure :) -- Koos (mobile)

This discussion belongs on python-list (where is it mostly a repeat). -- Terry Jan Reedy

On 2017-07-27 03:34, Mike Miller wrote:

On 2017-07-26 16:36, MRAB wrote:

...

"nobreak" would introduce a new keyword, but "not break" wouldn't.

Whenever I've used the for-else, I've put a # no-break right next to it, to remind myself as much as anyone else.

for...: not break: is the best alternative I've yet seen, congrats. Perhaps in Python 5 it can be enabled, with for-else: used instead for empty iterables, as that's what I expected the first few dozen times.

For empty iterables, how about "elif None:"? :-)

elif break and elif None: I'd like that very much. It's weird a break the semantic of break and None, but it's in such a dark corner of Python anyway I don't bother. Le 27/07/2017 à 21:19, MRAB a écrit :

On 2017-07-27 03:34, Mike Miller wrote:

...

On 2017-07-26 16:36, MRAB wrote:

...

"nobreak" would introduce a new keyword, but "not break" wouldn't.

Whenever I've used the for-else, I've put a # no-break right next to it, to remind myself as much as anyone else.

for...: not break: is the best alternative I've yet seen, congrats. Perhaps in Python 5 it can be enabled, with for-else: used instead for empty iterables, as that's what I expected the first few dozen times.

For empty iterables, how about "elif None:"? :-) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/desmoulinmichel%40gmail.c...

On 28/07/2017 20:57, MRAB wrote:

On 2017-07-28 10:17, Michel Desmoulin wrote:

...

elif break and elif None: I'd like that very much. It's weird a break the semantic of break and None, but it's in such a dark corner of Python anyway I don't bother.

Surely it would not be "elif break", but "elif not break"? To me, anything beginning with "else" or "elif" suggests an alternative branch, not an additional one (YMMV): if condition: do_something else: do_something_completely_different

Therefore I would find "if not break" or even "and if not break" more intuitive. Best wishes Rob Cliffe

...

Le 27/07/2017 à 21:19, MRAB a écrit :

...

On 2017-07-27 03:34, Mike Miller wrote:

...

On 2017-07-26 16:36, MRAB wrote:

...

"nobreak" would introduce a new keyword, but "not break" wouldn't.

Whenever I've used the for-else, I've put a # no-break right next to it, to remind myself as much as anyone else.

for...: not break: is the best alternative I've yet seen, congrats. Perhaps in Python 5 it can be enabled, with for-else: used instead for empty iterables, as that's what I expected the first few dozen times.

For empty iterables, how about "elif None:"? :-)

---

Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rob.cliffe%40btinternet.c...

--- This email has been checked for viruses by AVG. http://www.avg.com