
Hello, I think that the expression "for...else" or "while...else" is completely counter-intuitive. Wouldn't it be possible to make it clearer? Maybe something like break in for i in range(n): ... if cond: break else: ... I'm not an English native speaker so I don't know whether "break in" is acceptable English in this context or can only mean "to get into a building by force". Kiuhnm

Hello Kiuhnm, and welcome. On Mon, Jul 24, 2017 at 05:35:03PM +0200, Kiuhnm via Python-Dev wrote:
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

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 <steve@pearwood.info> wrote:

On 25 July 2017 at 02:23, Ben Hoyt <benhoyt@gmail.com> wrote:
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 <steve@pearwood.info> wrote:
IMO, for item in sequence: # block nobreak: # or perhaps `if not break:` # block would be clearer (if the syntax is necessary at all). [...]
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
[...] -- + Koos Zevenhoven + http://twitter.com/k7hoven +

On Jul 27, 2017 02:38, "MRAB" <python@mrabarnett.plus.com> wrote: On 2017-07-26 23:55, Koos Zevenhoven wrote:
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)

On 2017-07-27 01:07, Koos Zevenhoven wrote:
I suppose you _could_ use "if not break:", but as 'if' normally indicates the start of an 'if' statement, you would get complaints about it! :-) Maybe it would be clearer if it was "elif not break:". :-)
"nobreak" would introduce a new keyword, but "not break" wouldn't.
Sure :)

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

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

funny ; this made me think of this talk; https://youtu.be/OSGv2VnC0go?t=1013 Éric Lafontaine | Membre du Projet VUE, Groupe Contrôle Génie électrique, 54ème promotion UdeS | Étudiant en maitrise TI à l'ETS VAS OPS chez Bell Mobility « Nous voulons proposer une alternative de transport en présentant un véhicule électrique spécifiquement conçu pour les déplacements urbains. » 2017-07-27 15:19 GMT-04:00 MRAB <python@mrabarnett.plus.com>:

The way I remember it is to observe that the following are *almost* exactly the same thing: if C: T else: E while C: T else: E The *only* differences are: 1) where execution jumps if it reaches the end of the T: in the "while", it jumps back to the while itself, resulting in the condition being rechecked, whereas in the "if" execution skips over the "else" to whatever follows; and 2) in the "while", inside the T "break" and "continue" relate to this control structure rather than to a containing loop. (At least I don't think I'm missing any other differences!) Seen this way, the meaning of the "else" is easy to understand and to remember. And the for loop else is like the while loop else. On 24 July 2017 at 11:35, Kiuhnm via Python-Dev <python-dev@python.org> wrote:

Hello Kiuhnm, and welcome. On Mon, Jul 24, 2017 at 05:35:03PM +0200, Kiuhnm via Python-Dev wrote:
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

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 <steve@pearwood.info> wrote:

On 25 July 2017 at 02:23, Ben Hoyt <benhoyt@gmail.com> wrote:
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 <steve@pearwood.info> wrote:
IMO, for item in sequence: # block nobreak: # or perhaps `if not break:` # block would be clearer (if the syntax is necessary at all). [...]
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
[...] -- + Koos Zevenhoven + http://twitter.com/k7hoven +

On Jul 27, 2017 02:38, "MRAB" <python@mrabarnett.plus.com> wrote: On 2017-07-26 23:55, Koos Zevenhoven wrote:
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)

On 2017-07-27 01:07, Koos Zevenhoven wrote:
I suppose you _could_ use "if not break:", but as 'if' normally indicates the start of an 'if' statement, you would get complaints about it! :-) Maybe it would be clearer if it was "elif not break:". :-)
"nobreak" would introduce a new keyword, but "not break" wouldn't.
Sure :)

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

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

funny ; this made me think of this talk; https://youtu.be/OSGv2VnC0go?t=1013 Éric Lafontaine | Membre du Projet VUE, Groupe Contrôle Génie électrique, 54ème promotion UdeS | Étudiant en maitrise TI à l'ETS VAS OPS chez Bell Mobility « Nous voulons proposer une alternative de transport en présentant un véhicule électrique spécifiquement conçu pour les déplacements urbains. » 2017-07-27 15:19 GMT-04:00 MRAB <python@mrabarnett.plus.com>:

The way I remember it is to observe that the following are *almost* exactly the same thing: if C: T else: E while C: T else: E The *only* differences are: 1) where execution jumps if it reaches the end of the T: in the "while", it jumps back to the while itself, resulting in the condition being rechecked, whereas in the "if" execution skips over the "else" to whatever follows; and 2) in the "while", inside the T "break" and "continue" relate to this control structure rather than to a containing loop. (At least I don't think I'm missing any other differences!) Seen this way, the meaning of the "else" is easy to understand and to remember. And the for loop else is like the while loop else. On 24 July 2017 at 11:35, Kiuhnm via Python-Dev <python-dev@python.org> wrote:
participants (14)
-
Alexander Belopolsky
-
Ben Hoyt
-
Eric Lafontaine
-
Isaac Morland
-
Kiuhnm
-
Koos Zevenhoven
-
Larry Hastings
-
Michel Desmoulin
-
Mike Miller
-
MRAB
-
Nick Coghlan
-
Rob Cliffe
-
Steven D'Aprano
-
Terry Reedy