Why single out for/while and leave out try? It supports an else statement in a similar fashion. Honestly I think the syntax is fine as it is. Once I grasped what it did and why, I exploited it to great effect. The syntax may be unfamiliar to programmers coming from other languages, but so what? The same can be said of every language on the planet. (I felt like an idiot when I started to learn Haskell). FWIW, nothing in life is intuitive. Absolutely nothing. Everything has to be learned, even the simplest things. A baby has to learn how to nurse and many struggle with that unintuitive process as well. The concept of what is "intuitive" is entirely in the eye of the beholder and is effectively a non-concept. -1. On Wed, Sep 30, 2009 at 9:58 PM, Yuvgoog Greenle <ubershmekel@gmail.com> wrote:

I wouldn't modify the way for/else behaves btw. I would either: 1. rename the "else" to something else for "for" and "while" loops 2. remove the syntax altogether. 2to3 or 3to4 can do this by changing a boolean before the "break" statement for example.

...

expectations of those unwilling to learn the language

I can tell you I love python and of course many newcomers will/do too. I'm just noting that this might be a pimple worth popping.

One more thing, I have to clear django's name as it doesn't have a for/else construct, it has a for/empty construct that was inspired by a popular for/else django template recipe entitled:

...

"for" template tag with support for "else" if array is empty

(thanks for pointing that out Karen) On Thu, Oct 1, 2009 at 4:35 AM, alex23 <wuwei23@gmail.com> wrote:

...

On Oct 1, 11:07 am, Yuvgoog Greenle <ubershme...@gmail.com> wrote:

...

To make things worse, it's not that newcomers will say "hmm, what does this for/else thing do? lets look at the manual", they will mistakenly assume they understand what the construct means.

-1 for modifying Python to meet the "intuitive" expectations of those unwilling to learn the language. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Gerald Britton

Yuvgoog Greenle writes:

I wouldn't modify the way for/else behaves btw. I would either:1. rename the "else" to something else for "for" and "while" loops

If you prefer some existing keyword, -0.75, else -1. Note: As a native speaker, since "for ... else" isn't English, I would certainly look up the semantics before using the syntax. This is very probably true for Japanese as well, who are far better at (consciously) remembering English syntax than native speakers are. I don't know about other non-natives.

2. remove the syntax altogether.

-1. It's occasionally useful, and when it is, it's nice and concise.

Thank god for empirical evidence and thanks Antti for the measurement. This construct should have been named "finally", "didnt_break" or "not break": while self.more_points_to_check(): if self.found_it(): # Found the desired point breaknot break: # Exhausted the search space :( On Thu, Oct 1, 2009 at 2:00 PM, Antti Rasinen <ars@iki.fi> wrote:

...

Yuvgoog Greenle schrieb:

...

On python-dev the subject of for/else statements came up, so I had to mention how "ambiguous" the syntax seems to me. By "ambiguous" I meant that it's not obvious what should happen in the for/else and while/else constructs (the except/else construct is readable and great imo btw).

Even though it's documented, for me it's a bad construct because it can and will always be misinterpreted by a non-trivial amount of people seeing it for the first time. It's unreadable and confusing because the "else" isn't referring to the "for" it's in reference to the "break". The construct is only useful in loops with "break" statements, so in pseudo code or human the "else" would have probably been translated to "if didn't break".

I agree that the "else" clause is somewhat unintuitive. However, it has its uses and can often replace more awkward constructs. As such, I would be -1 on removing it, and -3 on reusing the else clause for some other purpose.

I must say that calling for ... else "somewhat unintuitive" is the understatement of the year. The analogy with if ... else leads further astray than Odysseus.

The feature itself is not bad. It's just that it is misnamed.

I did a quick poll at the office and at IRC, five people in total, with 2-8 years of Python experience. Two had never heard of the for..else -construct; one had heard that it exists and two know about it but have never used it. Three uninitiated, in other words.

All three gave similar replies: if the loop is not executed or the variable is not iterable, then the else-branch is executed. Here are their reactions, when they learned how it really works:

* "It should be called for..then" (or for..finally) * "WHAT. No f** way. Completely unintuitive" * "I'd hate whoever wrote that code"

These people are actual Python developers, not some newbies. And I completely agree with them. I've only once seen for...else in the wild and never used it myself.

To add further insult to the naming injury, the else branch suffers from the fact that 99.9% of the time, the for-loop contains an if:

for x in xs: if cond(x): break # stuff else: # more stuff

My code pattern matching algorithm reads that as an indentation error. An else matches if so many times more often that decoding for..else requires unnecessary effort.

I don't want the feature to be removed or even renamed (at least before Python 4). But the feature *is* badly named and unintuitive.

-- [ Antti Rasinen <*> ars@iki.fi ]

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Yuvgoog Greenle wrote:

This construct should have been named "finally", "didnt_break" or "not break":

"finally" would be at least as confusing as "else", since by analogy with try-finally it suggests that it will *always* be executed, which isn't the case. -- Greg

On Thu, 8 Oct 2009 12:10:00 am Gerald Britton wrote:

Are you sure? Under what conditions would the "finally" clause be bypassed?

Are you talking about the existing try...finally clause, or the hypothetical "let's rename for...else to for...finally" clause? If the second, then it would be bypassed under exactly the same conditions as the else in for...else is bypassed. E.g.: for x in [1, 2, 3]: raise Exception else: print "This is never printed" def test(): for x in [1, 2, 3]: return x else: print "This is never printed" Renaming 'for...else' to 'for...finally' doesn't turn it into a try block. The semantics remain the same. -- Steven D'Aprano

That's what I was getting at. As long as Python doesn't crash or the process is not killed by some external force (e.g. power failure), the finally clause of a try/except/finally will always be executed. On Wed, Oct 7, 2009 at 10:18 AM, Masklinn <masklinn@masklinn.net> wrote:

On 2 Oct 2009, at 03:35 , Greg Ewing wrote:

...

Yuvgoog Greenle wrote:

...

This construct should have been named "finally", "didnt_break" or "not break":

"finally" would be at least as confusing as "else", since by analogy with try-finally it suggests that it will *always* be executed, which isn't the case.

Then again, a try's finally isn't *always* executed. It's *almost always* executed, but if the runtime (or just the thread the block is in) crashes, is killed with kill -9 or the machine is shut down, it won't be.

Interestingly, because sys.exit throws an exception instead of killing the runtime, the finally block does run if you call sys.exit in the try block (in Java, it doesn't) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Gerald Britton

2009/10/1 Antti Rasinen <ars@iki.fi>:

I must say that calling for ... else "somewhat unintuitive" is the understatement of the year. The analogy with if ... else leads further astray than Odysseus.

The feature itself is not bad. It's just that it is misnamed. [...] I don't want the feature to be removed or even renamed (at least before Python 4). But the feature *is* badly named and unintuitive.

I agree. I use it from time to time and I used to have to look up the docs every time, because I couldn't remember wheteher the 'else:' clause meant 'if did break' or 'if didn't break'. I solved this problem by stopping thinking about it as while-else or for-else, but rather as break-else. -- Arnaud

On Thu, Oct 1, 2009 at 4:00 AM, Antti Rasinen <ars@iki.fi> wrote:

I must say that calling for ... else "somewhat unintuitive" is the understatement of the year.

"The nipple is the only thing that's intuitive. Everything else is learned." -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Thu, Oct 01, 2009 at 07:47:37AM -0700, Guido van Rossum wrote:

On Thu, Oct 1, 2009 at 4:00 AM, Antti Rasinen <ars@iki.fi> wrote:

...

I must say that calling for ... else "somewhat unintuitive" is the understatement of the year.

"The nipple is the only thing that's intuitive. Everything else is learned."

"There is no intuitive interface, not even the nipple. It's all learned." http://www.greenend.org.uk/rjk/2002/08/nipple.html Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

Let me rephrase - for..else is a _misleading_ construct. It suggests one thing yet does another. This response is way too long, so here's a TOC: 1. The Question Challenge - A way to examine if "for..else" is just unintuitive or misleading. 2. What can be done about for...else. 3. Lets talk about "try/else" because a few people mentioned it as though it's somehow related to the discussion. ---------------- 1. The Question Challenge - A way to examine if "for..else" is just unintuitive or misleading. Antti's experiment got me asking, you can try this as well. Ask a person who knows python the following questions: Question #1: Do you know what happens when an "else" appears after a "for" loop? if they answer yes then say nevermind. otherwise: continue to question #2. Question #2: When would the code in the "else" block execute? If you don't know, it's ok to guess. If they answer "when a break didn't occur", I'm willing to give you, the asker, up to 100 lines of patch code in whatever python project you want.. If they answer "maybe when the for loop didn't run or was an empty list" then you don't owe me anything. ------------- 2. What can be done about for...else. 1. Not allowing a for loop that has no "break" to have an "else". Just like "else" isn't allowed when there isn't an "except" in the "try". There really is no excuse, justification or sense in a "for" loop that has no "break" yet has an "else". 2. Lets not talk about removing the "else" from for/while completely since it does have its fans and cute use cases. 3. Renaming this construct for py4k wouldn't be too crazy if you use the existing reserved words "not" and "break". Look at this code and please note that it doesn't need any comments to make it readable (as opposed to Nick's example, no offence): for item in list_of_stuff: if item.is_awesome(): break not break: print("nothing is awesome :(") And I can even think of a few use cases for having just "break:". This block would execute only upon "break" occurring. That way you could have loops like this: for item in list_of_stuff: if item.is_awesome(): break break: celebrate(list_of_stuff) -------------------------- 3. Lets talk about "try/else" because a few people mentioned it as though it's somehow related to the discussion. "try/else" now _that_ is a red herring. There is no "try/else". OTOH "except/else", as I said before, is a beautiful, pythonic, useful and cool construct. This is the evidence:

...

...

try: ... print(1) ... else: File "<stdin>", line 3 else: ^ SyntaxError: invalid syntax try: ... print(2) ... finally: ... print(3) ... else: File "<stdin>", line 5 else: ^ try: ... print(7) ... except Exception as e: ... print(13) ... else: ... print(6) ... 7 6

Yuvgoog Greenle writes:

1. Not allowing a for loop that has no "break" to have an "else". Just like "else" isn't allowed when there isn't an "except" in the "try". There really is no excuse, justification or sense in a "for" loop that has no "break" yet has an "else".

+1. File an RFE against PyLint for sure, and against Python too. That's a *great* idea! Bikeshedding follows.

Antti's experiment got me asking, you can try this as well. Ask a person who knows python the following questions: Question #1: Do you know what happens when an "else" appears after a "for" loop? if they answer yes then say nevermind.

Er, no. It's more important if what people "know" is wrong than if naive guesses are wrong.

otherwise: continue to question #2. Question #2: When would the code in the "else" block execute? If you don't know, it's ok to guess.

I would fire a programmer who gave an answer.<0.5 wink> He might do the same in his own code or in a review of someone else's.

3. Renaming this construct for py4k wouldn't be too crazy if you use the existing reserved words "not" and "break". Look at this code and please note that it doesn't need any comments to make it readable (as opposed to Nick's example, no offence):

Nick's example is far more readable IMO. No offense. I can tell you why, too. In his example, the "else" is immediately preceded by the "if ... break" suite. Because "break" can only happen once in a loop, I read the else as the alternative to breaking out. Sloppy, yes, but since this is the common idiom using for-else, it works for me. :-) OTOH, "break" is an imperative; "not break" looks like a prohibition to me, not the target of a branch. You could use "for: ... if not break:" but that looks ugly to me, and worse requires several tokens of lookahead to disambiguate from an ordinary if block. I'll leave it up to GvR to decide whether for-else is "less Pythonic" than try-except-else.

And I can even think of a few use cases for having just "break:". This block would execute only upon "break" occurring. That way you could have loops like this:

for item in list_of_stuff: if item.is_awesome(): break break: celebrate(list_of_stuff)

You'd need multiple breaks for this to make sense. Else: for item in list_of_stuff: if item.is_awesome(): celebrate(list_of_stuff) break Some people think that having multiple breaks is bad style.

Nonsense - there are several other ways to break out of a loop. Raising an exception or returning for example

I do appreciate your response. I'd like you to examine how the "else" in question isn't relevant to the discussion of return or raise:

...

...

for i in range(10): ... print(1/0) ... else: ... print(100) ... Traceback (most recent call last): File "<stdin>", line 2, in <module> ZeroDivisionError: int division or modulo by zero

def eggs(): ... for i in range(10): ... return 1234 ... else: ... print(69) ... eggs() 1234

I think I understand what you're saying and I just don't understand how it pertains to for..else. Specifically I would like an explanation about why the following quote is nonsense to you. 2009/10/2 Stephen J. Turnbull <stephen@xemacs.org> Yuvgoog Greenle writes:

...

1. Not allowing a for loop that has no "break" to have an "else". Just like "else" isn't allowed when there isn't an "except" in the "try". There really is no excuse, justification or sense in a "for" loop that has no "break" yet has an "else".

+1. File an RFE against PyLint for sure, and against Python too. That's a *great* idea!

I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement: for i, j in enumerate(something): # suite i += 1 else: i = 0 # i == number of things processed The thing here is, "i" won't be set by the "for" statement if "something" is empty. OTOH, if "something" is non-empty, i >= 1 at the end of the for-loop. Using the "else" clause in this way ensure that "i" has the number of things processed at the end of the loop. To do this without the "else" I have to: i = 0 for i, j in enumerate(something): # suite i += 1 I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement: for i, j in enumerate(something): # suite i += 1 else: i = 0 # i == number of things processed Does it work? Sure! But it moves the setting of "i" outside the for-construct, which I personally dislike. On Fri, Oct 2, 2009 at 8:58 AM, Michael Foord <fuzzyman@gmail.com> wrote:

2009/10/2 Yuvgoog Greenle <ubershmekel@gmail.com>

...

I think I understand what you're saying and I just don't understand how it pertains to for..else. Specifically I would like an explanation about why the following quote is nonsense to you.

Hmm... on consideration, breaking out of a loop without a break (i.e. exception or return) wouldn't enter the else clause *anyway*, so there is still no need for the else clause.

My apologies, I retract. :-)

Michael

...

...

2009/10/2 Stephen J. Turnbull <stephen@xemacs.org>

Yuvgoog Greenle writes:

 > 1. Not allowing a for loop that has no "break" to have an "else". Just like  > "else" isn't allowed when there isn't an "except" in the "try". There really  > is no excuse, justification or sense in a "for" loop that has no "break" yet  > has an "else".

+1.  File an RFE against PyLint for sure, and against Python too. That's a *great* idea!

-- http://www.ironpythoninaction.com/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Gerald Britton

Nope:

...

...

l = [] for i,j in enumerate(l): pass ... i Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'i' is not defined

"i" is not initialized if "l" is empty. On Fri, Oct 2, 2009 at 9:54 AM, Yuvgoog Greenle <ubershmekel@gmail.com> wrote:

On Fri, Oct 2, 2009 at 4:46 PM, Gerald Britton <gerald.britton@gmail.com> wrote:

...

I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement:

for i, j in enumerate(something):  # suite  i += 1 else:  i = 0

# i == number of things processed

Sorry, there must be some typo in your code. The "i" is always 0 after the loop unless you break.

...

...

...

for i, j in enumerate(range(10)): ...     i +=1 ... else: ...     i = 0 ... i 0

Also, why would one increment the enumeration index "i" by hand?

-- Gerald Britton

Those who believe that the for/else construct is sufficiently clear, please read this email again: Gerald Britton:

I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement:

for i, j in enumerate(something):  # suite  i += 1 else:  i = 0

# i == number of things processed

The thing here is, "i" won't be set by the "for" statement if "something" is empty.  OTOH, if "something" is non-empty, i >= 1 at the end of the for-loop.  Using the "else" clause in this way ensure that "i" has the number of things processed at the end of the loop.

To do this without the "else" I have to:

i = 0 for i, j in enumerate(something):  # suite  i += 1 I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement:

for i, j in enumerate(something):  # suite  i += 1 else:  i = 0

# i == number of things processed

Does it work?  Sure!  But it moves the setting of "i" outside the for-construct, which I personally dislike.

I don't mean to pick on Gerald, but he got the meaning of for/else dead wrong *in the middle of a debate about for/else*. This shows that even experienced Pythoneers who read Python-ideas can be confused about the meaning of for/else. Using it in production code means leaving a trap for the programmers who come after you and read your code to get confused and create a bug. Yes, when the others turn your working use of for/else into a bug, it's their fault for not reading the tutorial more closely so as not get confused by it, but ultimately no matter how much you blame the user, that won't stop the next guy who uses your code from misunderstanding it. The best solution to this inherent confusingness is to leave bare for/else alone for the foreseeable future, but to add a less confusing synonym for this feature. I propose "else not break:" although "elif not break:" is good too. Rewriting Gerald's example as for i, j in enumerate(something): # suite i += 1 else if not break: i = 0 # i == number of things processed makes it 100% smack you in the face obvious that "Oh yeah, this is going to set i to 0 every time, since there's no break." In an unrelated but also good idea, it would be nice to be able to do what Gerald thought he was doing: for i, j in enumerate(something): # suite i += 1 else if None: #or some other suitable phrase for "empty" i = 0 # i == number of things processed — Carl

Steven D'Aprano:

You can already do this today, with no change to the compiler, using only a slightly different syntax to that suggested:

for i, j in enumerate(something):    # suite    i += 1 else:  # if not break    i = 0

Best of all, it's an extensible syntax, so there's no need for bike-shedding arguments about whether it should be spelled "not break" or "no break" or "didn't break" or "only if loop ended normally". All of these variants, and more, are accepted:

Hoisted by my own petard! :-D This was also my suggestion for adding a do-while to Python a few weeks back: while True: #do { stuff # } until { if cond: break # } — Carl

Sory Carl, I did NOT get it dead wrong. The else is executed if the for loop falls through. That's the whole idea. Probably I should have set i to -1 in the else clause of the toy example though: for i, j in enumerate(something): # do something i += 1 else: i = -1 if i > 0: # we did something If you don't think the else is executed when the for-loop falls through, then you should re-read the documentation, here: http://docs.python.org/reference/compound_stmts.html#the-for-statement Where it says (just as I did, but in other words): "When the items are exhausted (which is immediately when the sequence is empty), the suite in the else clause, if present, is executed, and the loop terminates." On Fri, Oct 2, 2009 at 9:18 PM, Carl Johnson <cmjohnson.mailinglist@gmail.com> wrote:

Those who believe that the for/else construct is sufficiently clear, please read this email again:

Gerald Britton:

...

I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement:

for i, j in enumerate(something):  # suite  i += 1 else:  i = 0

# i == number of things processed

The thing here is, "i" won't be set by the "for" statement if "something" is empty.  OTOH, if "something" is non-empty, i >= 1 at the end of the for-loop.  Using the "else" clause in this way ensure that "i" has the number of things processed at the end of the loop.

To do this without the "else" I have to:

i = 0 for i, j in enumerate(something):  # suite  i += 1 I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement:

for i, j in enumerate(something):  # suite  i += 1 else:  i = 0

# i == number of things processed

Does it work?  Sure!  But it moves the setting of "i" outside the for-construct, which I personally dislike.

I don't mean to pick on Gerald, but he got the meaning of for/else dead wrong *in the middle of a debate about for/else*. This shows that even experienced Pythoneers who read Python-ideas can be confused about the meaning of for/else. Using it in production code means leaving a trap for the programmers who come after you and read your code to get confused and create a bug. Yes, when the others turn your working use of for/else into a bug, it's their fault for not reading the tutorial more closely so as not get confused by it, but ultimately no matter how much you blame the user, that won't stop the next guy who uses your code from misunderstanding it.

The best solution to this inherent confusingness is to leave bare for/else alone for the foreseeable future, but to add a less confusing synonym for this feature. I propose "else not break:" although "elif not break:" is good too. Rewriting Gerald's example as

for i, j in enumerate(something):  # suite  i += 1 else if not break:  i = 0

# i == number of things processed

makes it 100% smack you in the face obvious that "Oh yeah, this is going to set i to 0 every time, since there's no break."

In an unrelated but also good idea, it would be nice to be able to do what Gerald thought he was doing:

for i, j in enumerate(something):  # suite  i += 1 else if None: #or some other suitable phrase for "empty"  i = 0

# i == number of things processed

— Carl _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Gerald Britton

Yes, quite right. Another way would be: for i, j in enumerate(x): # do something i += 1 else: if "i" not in vars(): i = 0 Is it better than initializing before? Not sure. I guess it's a matter of taste. On Sat, Oct 3, 2009 at 11:22 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

Gerald Britton wrote:

...

Sory Carl, I did NOT get it dead wrong.  The else is executed if the for loop falls through.  That's the whole idea.  Probably I should have set i to -1 in the else clause of the toy example though:

for i, j in enumerate(something):   # do something   i += 1 else:  i = -1

if i > 0:   # we did something

If you don't think the else is executed when the for-loop falls through, then you should re-read the documentation, here:

http://docs.python.org/reference/compound_stmts.html#the-for-statement

Where it says (just as I did, but in other words):

"When the items are exhausted (which is immediately when the sequence is empty), the suite in the else clause, if present, is executed, and the loop terminates."

The code in your example is semantically identical to the following:

 for i, j in enumerate(something):    # do something    i += 1  i = -1

 if i > 0:    # This block is unreachable...

Without a break statement in the body of the loop the else will by executed unconditionally, hence it is exactly the same as if the code it contains was just inline after the loop body.

The semantics you describe can be obtained only by initialising i before the loop:

 i = -1  for i, j in enumerate(something):    # do something    i += 1

 if i >= 0:    # We did something

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia ---------------------------------------------------------------

-- Gerald Britton

On 3 Oct 2009, at 13:49 , Gerald Britton wrote:

Sory Carl, I did NOT get it dead wrong. The else is executed if the for loop falls through. That's the whole idea. Probably I should have set i to -1 in the else clause of the toy example though:

for i, j in enumerate(something): # do something i += 1 else: i = -1

if i > 0: # we did something

If you don't think the else is executed when the for-loop falls through, then you should re-read the documentation, here: Carl didn't dispute that point. In fact that's exactly the issue with your code: since you don't have any `break` statement in your `for:` loop, the `else:` clause will *always* be executed, whether `something` is an empty collection or not.

Thus, the following `if i > 0:` clause cannot under any circumstance be executed. Your code (unless there is a break in the 'do something' part) is equivalent to: for i, j in enumerate(something): # do something i += 1 i = -1 if i > 0: # can never happen

Gerald Britton writes:

Sory Carl, I did NOT get it dead wrong. The else is executed if the for loop falls through.

for i, j in enumerate(something): # do something i += 1 else: i = -1

Carl's point (revised to correspond to the new example) is assert(i == -1) so

if i > 0: # we did something

is dead code.

Stephen J. Turnbull wrote:

Yuvgoog Greenle writes:

...

I think I understand what you're saying and I just don't understand how it pertains to for..else. Specifically I would like an explanation about why the following quote is nonsense to you.

I didn't say it was nonsense and I didn't mean it was nonsense.

I can see no reason at all why PyLint wouldn't warn about "breakless for-else". "raise StopIteration" and "if __debug__: break" *may* be sufficient reason Python itself shouldn't be too noisy, but for sure PyLint should warn about it.

raise StopIteration in the body of the for loop will escape, just like any other suggestion. However, Gerald's point that the else clause can also be used to give the iteration variable a "default" value (with nary a break in sight) in addition to the more traditional search loop idiom is enough to convince me that the compiler should stay out of this one. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Footnotes: [1]  StopIteration can, but I thought raising StopIteration in user code is considered quite bad form.

StopIteration once put forward on this very list as a way to stop a generator. e.g. def stop(): raise StopIteration gen = (x in something if <x meets some condition> or stop() ) Toy example: Say you want the squares of all natural numbers n such that n <= j. Here's one simple way using the stop function above: from itertools import count squares = (n**2 for n in count() if n <= j or stop() ) Without the "or stop()" the generator goes into an infinite loop when n exceeds 10. Of course you can do this toy example other ways, this is just an illustration.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Gerald Britton

Michael Foord wrote:

Nonsense - there are several other ways to break out of a loop. Raising an exception or returning for example.

But both of those bypass any code following the for-loop, so there is no need for an else-clause in those cases. -- Greg

On Fri, 2 Oct 2009 09:01:20 pm Nick Coghlan wrote:

Yuvgoog Greenle wrote:

...

1. Not allowing a for loop that has no "break" to have an "else". Just like "else" isn't allowed when there isn't an "except" in the "try". There really is no excuse, justification or sense in a "for" loop that has no "break" yet has an "else".

As Stephen said, that's a very good point. Having the compiler issue a SyntaxWarning when compiling such code is perfectly possible and would make a great deal of sense (and probably prevent many cases of naive misuse).

I disagree that it makes sense. Why raise a SyntaxWarning for legal code? Shall we raise SyntaxWarning for the following as well? #1 pass pass #2 if False: parrot() #3 for x in []: do_something() #4 try: something() except Exception: raise etc. There are all sorts of code which is legal but does nothing. Why should the language single out one of them for a warning? If that warning is anywhere, it should be in PyLint or equivalent. It's even more problematic when you consider code where the break is inside a "if __debug__" clause. Then you've code which raises a warning when you run with the -O flag, and doesn't when you run without. -- Steven D'Aprano

Nick Coghlan wrote:

Steven D'Aprano wrote:

...

On Fri, 2 Oct 2009 09:01:20 pm Nick Coghlan wrote:

...

Yuvgoog Greenle wrote:

...

1. Not allowing a for loop that has no "break" to have an "else". Just like "else" isn't allowed when there isn't an "except" in the "try". There really is no excuse, justification or sense in a "for" loop that has no "break" yet has an "else". As Stephen said, that's a very good point. Having the compiler issue a SyntaxWarning when compiling such code is perfectly possible and would make a great deal of sense (and probably prevent many cases of naive misuse). I disagree that it makes sense. Why raise a SyntaxWarning for legal code?

Yeah, I was wrong. Definitely in pylint/pychecker territory.

After the additional posts in the discussion, I'm back to my previous opinion - the construct should be referred to as break/else (or for/break/else and while/break/else) and we should at least investigate having the compiler itself raise at least a SyntaxWarning if it encounters a for/else or while/else construct without also encountering a break statement inside the loop. The situation is *exactly* analagous to try/except/else: if there is no except clause, then using the "else" is redundant - just put the code inside the try block (if there is also a finally clause) or ditch the try statement altogether (if there is no finally clause). The compiler enforces this by treating try/else with no except clause as a SyntaxError. For a loop with no break statements the else clause will *always* be executed, hence using the clause is completely redundant - the code it contains might as well be dedented and placed inline at the same level as the loop header. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Nick Coghlan wrote:

Nick Coghlan wrote:

For a loop with no break statements the else clause will *always* be executed, hence using the clause is completely redundant - the code it contains might as well be dedented and placed inline at the same level as the loop header.

The loop could have a "return", "raise", or be inside a "try/except" instead of having a "break". Cheers, Ron

Nick Coghlan wrote:

Ron Adam wrote:

...

Nick Coghlan wrote:

...

Nick Coghlan wrote:

...

For a loop with no break statements the else clause will *always* be executed, hence using the clause is completely redundant - the code it contains might as well be dedented and placed inline at the same level as the loop header. The loop could have a "return", "raise", or be inside a "try/except" instead of having a "break".

As I've said elsewhere in this thread, while the else clause won't be executed in those cases, neither will any code that occurs immediately after the loop statement. Accordingly, using the else clause is unnecessary and rather misleading - just writing the extra code after the loop would be much clearer.

The number one thing I have learned from this thread is the fact that the else clause only makes sense when used in conjunction with a break statement and the fact that this construct isn't regularly documented and explained as for/break/else and while/break/else is the major barrier to understanding what it does.

Cheers, Nick.

Ahh, Ok, I agree. Documenting them as for/break/else and while/break/else would probably reduce 80% of the confusion people have with it. Ron

Yuvgoog Greenle wrote:

Document it as much as you want but the "else" doesn't hint or clue as to whether it catches breaks or is skipped by them.

The next problem's gonna be at midnight when you're reading code and asking yourself "hmmm, for, blah blah, else, hmm oh yeah, else-break, so this else occurs whenever there's a break."

True, and that is part of the other 20% I expect the documentation would't help. The only solution to that that I can think of is to change the esle's in for and while loops to for/then and while/then in Python 5.0. It might be doable, and if enough people want it, then just maybe...

On Sat, Oct 3, 2009 at 6:27 PM, Ron Adam <rrr@ronadam.com> wrote:

...

Nick Coghlan wrote:

...

...

Nick Coghlan wrote:

...

Nick Coghlan wrote: For a loop with no break statements the else clause will *always* be executed, hence using the clause is completely redundant - the code it contains might as well be dedented and placed inline at the same level as the loop header. The loop could have a "return", "raise", or be inside a "try/except" instead of having a "break". As I've said elsewhere in this thread, while the else clause won't be executed in those cases, neither will any code that occurs immediately after the loop statement. Accordingly, using the else clause is unnecessary and rather misleading - just writing the extra code after

Ron Adam wrote: the loop would be much clearer.

The number one thing I have learned from this thread is the fact that the else clause only makes sense when used in conjunction with a break statement and the fact that this construct isn't regularly documented and explained as for/break/else and while/break/else is the major barrier to understanding what it does.

Cheers, Nick. Ahh, Ok, I agree. Documenting them as for/break/else and while/break/else would probably reduce 80% of the confusion people have with it.

Ron

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Yuvgoog Greenle wrote:

On Sat, Oct 3, 2009 at 7:19 PM, Ron Adam <rrr@ronadam.com> wrote:

...

True, and that is part of the other 20% I expect the documentation would't help.

The only solution to that that I can think of is to change the esle's in for and while loops to for/then and while/then in Python 5.0.

It might be doable, and if enough people want it, then just maybe...

Documenting this syntax with the appropriate warnings and clear explanations is very important.

But I don't think the amount of code mishaps on this thread are properly addressed just by better documentation. The syntax I proposed is harmless, it won't break any existing code, and it's something people in python 3 can use right now. Deprecation etc can wait for python 4. Don't tea5e me :)

Lol, Sorry about that. ;-), but I do think it's too late to change for/else and while/else to for/then and while/then in python 4.0 already.

Of course people here would have to say if my idea sounds good or not.

while still_more_items(): if found_it(): break if not break: # exhausted search space

I suppose most people won't like the way break is used in two entirely different ways depending on where it is. When you see a break, two things become really clear: 1: you are inside a loop 2: we are exiting a loop When you use it in the other context it makes those things a bit less obvious especially if you consider loops inside of loops. We then have to consider the closeness these too statements are to each other. if not condition: break if not break: condition we aren't exiting a loop in the second case, even though it may be inside another loop. Cheers, Ron

On 3 Oct 2009, at 18:19 , Ron Adam wrote:

Yuvgoog Greenle wrote:

...

Document it as much as you want but the "else" doesn't hint or clue as to whether it catches breaks or is skipped by them. The next problem's gonna be at midnight when you're reading code and asking yourself "hmmm, for, blah blah, else, hmm oh yeah, else-break, so this else occurs whenever there's a break." True, and that is part of the other 20% I expect the documentation would't help.

The only solution to that that I can think of is to change the esle's in for and while loops to for/then and while/then in Python 5.0.

That would yield for val in vals: if cond(val): break # processing then: # more stuff how does it make the "alternate" clause being skipped in case of break any clearer?

Masklinn wrote:

On 3 Oct 2009, at 18:19 , Ron Adam wrote:

...

Yuvgoog Greenle wrote:

...

Document it as much as you want but the "else" doesn't hint or clue as to whether it catches breaks or is skipped by them. The next problem's gonna be at midnight when you're reading code and asking yourself "hmmm, for, blah blah, else, hmm oh yeah, else-break, so this else occurs whenever there's a break." True, and that is part of the other 20% I expect the documentation would't help.

The only solution to that that I can think of is to change the esle's in for and while loops to for/then and while/then in Python 5.0.

That would yield

for val in vals: if cond(val): break # processing then: # more stuff

how does it make the "alternate" clause being skipped in case of break any clearer?

I didn't say the behavior would change. for val in vals: if cond(val): break # processing val then: #all values processed # do more stuff The break would brake out of the entire for/then block. for val in vals: if found(val): searchval = val break then: # if not found searchval = default # breaks jumps to here I think that reads very well. :-) On the other hand "else" with the same comments really isn't all that much worse once you understand how break works in for/while loops. It's just a bit more of a hurdle for people new to python to get because of it's counter intuitive behavior compared else's use in if/else blocks. In those other languages that use case blocks, break is used to escape out of the entire case block in the same way break escapes out of the entire for/else blocks in python. Cheers, Ron

On Sat, 3 Oct 2009 01:42:48 am Yuvgoog Greenle wrote:

On Fri, Oct 2, 2009 at 5:35 PM, Steven D'Aprano <steve@pearwood.info> wrote:

...

I disagree that it makes sense. Why raise a SyntaxWarning for legal code? Shall we raise SyntaxWarning for the following as well?

#1 pass pass

#2 if False:    parrot()

#3 for x in []:    do_something()

#4 try:    something() except Exception:    raise

All of your examples do exactly what they appear to do.

And so does for..else with no break.

The for...else construct that has no "break" appears to do something, yet does nothing.

Nonsense.

...

...

for x in []: ... print "Do nothing" ... else: ... print "Do something" ... Do something

I beg of you to try out "The Question Challenge" I posted earlier. It's a win-win situation for you.

Your second question: [quote] Question #2: When would the code in the "else" block execute? If you don't know, it's ok to guess. [...] If they answer "maybe when the for loop didn't run or was an empty list" then you don't owe me anything. [end quote] But the else clause *does* run when the loop didn't run or was an empty list. That second answer would be correct, as far as it goes. It fails to describe all the behaviour of the else clause, but it's not wrong, merely incomplete.

If you're still not convinced, check out this code that is legal, yet appears to do something that it doesn't:

try:     z = math.sqrt(x / y) except ZeroDivisionError, ValueError:     print("Math error, try again")

Irrelevant. We're not talking about the syntax of the except statement. Why would confusing syntax there convince me that a *completely different* statement was also confusing? That's like saying, "If you don't agree that chocolate tastes terrible, have a taste of this cow-vomit. Terrible, right? So now we agree, chocolate tastes terrible." -- Steven D'Aprano

On 2 Oct 2009, at 20:43, Yuvgoog Greenle wrote:

Ask a person who knows python the following questions: Question #1: Do you know what happens when an "else" appears after a "for" loop? if they answer yes then say never mind. otherwise: continue to question #2. Question #2: When does the code in the "else" block execute? Of course you don't know so it's ok to guess. If they answer "when a break didn't occur", I'm willing to give you, the asker, up to 100 lines of patch code in whatever python project you want. If they answer "only when the for loop didn't run or was an empty list" then you don't owe me anything.

And then ask those same people if they know what a "data descriptor" is. There's some features of a language you just have to learn. And frankly, the for/else statement is very simple. It's surprising the first time you see it, but that's because few other languages have it. But, once you learn it, it's VERY handy. On 2 Oct 2009, at 22:08, Nick Coghlan wrote:

After the additional posts in the discussion, I'm back to my previous opinion - the construct should be referred to as break/else (or for/break/else and while/break/else) and we should at least investigate having the compiler itself raise at least a SyntaxWarning if it encounters a for/else or while/else construct without also encountering a break statement inside the loop.

I would disagree. Imagine, while trying to debug code, you comment out an if statement inside the for loop, and now suddenly the whole loop becomes syntactically invalid. Plus, it's not only a break that could potentially make a for/else a valid construct. Return and yield are both legitimate, and technically anything that can throw an exception is too. Trying to implement the lexer to scan for all the possible combinations does not seem to be worth the effort. Jared

It just hit me. The for...else is so cryptic because of one big issue - the "else". Consider the following code: for obj in iterable: if found_it(obj): # Found what we were looking for! break if not break: # It wasn't there :( Similarly for while loops: while self.more_points_to_check(): if self.found_it(): # Found the desired point break if not break: # Exhausted the search space :( Notice how readable and beautiful the code has become. We have 2 implementation options: 1. an "if" that comes immediately after a for/while can have the special keywords "not" or "break". 2. the for/while syntax has an optional "if break" or "if not break". I'd like to hear if people like this idea and if so, which of the 2 options do you like better. Check it out, there's no need for a syntax error because it's so obviously wrong: for item in list_of_items: process(item) if not break: do_something() Also, now that the syntax is generic, you can add on to it whatever you like. For example: for item in list_of_items: process(item) if item.is_gold(): break if item.is_silver(): break if break and searching_for_metals: celebrate(list_of_items) --yuv

Ok, in theory, it's possible to flag a boolean after a for/while when compiling, but I think the "special syntax" option might be simpler to implement. So let's talk grammar... The old grammar was: while_stmt ::= "while" expression ":" suite ["else" ":" suite] for_stmt ::= "for" target_list "in" expression_list ":" suite ["else" ":" suite] And the new one I propose looks like this: while_stmt ::= "while" expression ":" suite ["if" expression ":" suite] for_stmt ::= "for" target_list "in" expression_list ":" suite ["if" expression ":" suite] The "if" expression would be evaluated regularly but would have a magic boolean "break" that exists only in the if statement's expression eval. Note a few things: 1. the "if" would have been evaluated either way after the loop (exceptions/returns aside). 2. the only thing that's changed is the existence of the magic boolean "break". 3. You don't have to use it as the old "for...else" but you can and it's perfectly readable. I'm no expert on the compiler, but I have a strong feeling this is doable. On Sat, Oct 3, 2009 at 6:04 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

Yuvgoog Greenle wrote:

...

I'd like to hear if people like this idea and if so, which of the 2 options do you like better.

The compiler can't handle it - it will see the "if" as the start of a new statement.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia ---------------------------------------------------------------

Yuvgoog Greenle wrote:

Ok, in theory, it's possible to flag a boolean after a for/while when compiling, but I think the "special syntax" option might be simpler to implement. So let's talk grammar...

The old grammar was:

while_stmt ::= "while" expression ":" suite ["else" ":" suite]

for_stmt ::= "for" target_list "in" expression_list ":" suite ["else" ":" suite]

And the new one I propose looks like this:

while_stmt ::= "while" expression ":" suite ["if" expression ":" suite]

for_stmt ::= "for" target_list "in" expression_list ":" suite ["if" expression ":" suite]

The "if" expression would be evaluated regularly but would have a magic boolean "break" that exists only in the if statement's expression eval. Note a few things: 1. the "if" would have been evaluated either way after the loop (exceptions/returns aside). 2. the only thing that's changed is the existence of the magic boolean "break". 3. You don't have to use it as the old "for...else" but you can and it's perfectly readable.

I'm no expert on the compiler, but I have a strong feeling this is doable.

It means having to several tokens ahead before being able to tell whether you're continuing the current structure or starting another. Perhaps 'elif' instead? while still_more_items(): if found_it(): break elif not break: # exhausted search space If the body of loop wasn't executed at all: while still_more_items(): if found_it(): break elif pass: # empty search space

On Sat, Oct 3, 2009 at 6:04 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

...

Yuvgoog Greenle wrote:

...

I'd like to hear if people like this idea and if so, which of the 2 options do you like better. The compiler can't handle it - it will see the "if" as the start of a new statement.

On Sat, 3 Oct 2009 11:30:55 pm Yuvgoog Greenle wrote:

if not break: [...] Notice how readable and beautiful the code has become.

No I don't. It looks like you're testing against a boolean flag called "break".

We have 2 implementation options: 1. an "if" that comes immediately after a for/while can have the special keywords "not" or "break". 2. the for/while syntax has an optional "if break" or "if not break".

Or #3: don't change a thing.

I'd like to hear if people like this idea and if so, which of the 2 options do you like better.

No. Neither of them.

Check it out, there's no need for a syntax error

That's right.

because it's so obviously wrong:

Your reasoning is backwards. If it were obviously wrong, there *would* be need to have a syntax error:

...

...

4+*3 File "<stdin>", line 1 4+*3 ^ SyntaxError: invalid syntax

Syntax errors are for code which can't be compiled, not for code that does something unexpected, or unintuitive, or pointless. -- Steven D'Aprano

Steven D'Aprano wrote:

It's even more problematic when you consider code where the break is inside a "if __debug__" clause. Then you've code which raises a warning when you run with the -O flag, and doesn't when you run without.

Not necessarily -- the decision to issue the warning could be made at an earlier stage of processing than the one that optimises away the if. -- Greg

On Fri, 2 Oct 2009 09:06:11 pm Nick Coghlan wrote:

Just as there is no "try/else",

Perhaps there should be. Does anyone know why there isn't? It seems an arbitrary restriction to me, because the following pieces of code are not equivalent: # not currently legal try: if cond: raise ValueError else: print "no exception was raised" finally: print "done" versus: try: if cond: raise ValueError finally: print "done" print "no exception was raised"

but only "except/else", so there is no "for/else" or "while/else", but only "break/else".

That's certainly not true.

...

...

for x in [1, 2, 3]: ... pass ... else: ... print "else without break" ... else without break

Issuing a SyntaxWarning might be a good way to make that clear.

Such a warning would be spurious. -- Steven D'Aprano

On Fri, Oct 2, 2009 at 6:34 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

Steven D'Aprano wrote:

...

On Fri, 2 Oct 2009 09:06:11 pm Nick Coghlan wrote:

...

Just as there is no "try/else",

Perhaps there should be. Does anyone know why there isn't? It seems an arbitrary restriction to me, because the following pieces of code are not equivalent:

# not currently legal try:     if cond:         raise ValueError else:     print "no exception was raised" finally:     print "done"

Just drop the else line and you get the semantics you're after:

try:    if cond:        raise ValueError    print "no exception was raised" finally:    print "done"

Also, in English/programmer/pesudo-code/human language, the following: something: A else: B Conveys that either A occurred or B occurred. This is just something everybody is used to because everybody knows if/else. Consider the following code: except: print("A brave attempt") else: print("Yippee") It's easy to understand that either "except" occurred or "else" occurred. The only time this rule is broken in python is the for/else and while/else.

On 2 Oct 2009, at 15:43, Steven D'Aprano wrote:

Perhaps there should be. Does anyone know why there isn't? It seems an arbitrary restriction to me, because the following pieces of code are not equivalent:

# not currently legal try: if cond: raise ValueError else: print "no exception was raised" finally: print "done"

But the above is the same as: try: if cond: raise ValueError print "no exception was raised" finally: print "done"

versus: [...]

-- Arnaud

On Fri, 2 Oct 2009 17:12:25 +0100 Michael Foord <fuzzyman@gmail.com> wrote:

2009/10/2 Arnaud Delobelle <arnodel@googlemail.com>

...

On 2 Oct 2009, at 15:43, Steven D'Aprano wrote:

...

Perhaps there should be. Does anyone know why there isn't? It seems an arbitrary restriction to me, because the following pieces of code are not equivalent:

# not currently legal try: if cond: raise ValueError else: print "no exception was raised" finally: print "done"

But the above is the same as:

try: if cond: raise ValueError print "no exception was raised" finally: print "done"

But as always with Python, the code in the else clause is not protected by the except so that you do not incorrectly handle unexpected exceptions.

Um, there's not an except clause to protect anything there. In both cases, the code flows from the try: block to the else: block (even without the else: line) and then the finally: block, with an exception in the try: or else: block skipping the rest of both. Consider the three cases: 1) no exception raised - both cases print "no exception was raised" and "done". 2) exception in original try block - both cases just print "done". 3) exception in original else - both cases print whatever prints from the else block before the exception, and then "done". So the else: might as well be a pass. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On Thu, Oct 1, 2009 at 11:11 PM, Yuvgoog Greenle <ubershmekel@gmail.com>wrote:

Let me rephrase - for..else is a _misleading_ construct. It suggests one thing yet does another. This response is way too long, so here's a TOC: 1. The Question Challenge - A way to examine if "for..else" is just unintuitive or misleading. 2. What can be done about for...else. 3. Lets talk about "try/else" because a few people mentioned it as though it's somehow related to the discussion.

---------------- 1. The Question Challenge - A way to examine if "for..else" is just unintuitive or misleading.

Antti's experiment got me asking, you can try this as well. Ask a person who knows python the following questions: Question #1: Do you know what happens when an "else" appears after a "for" loop? if they answer yes then say nevermind. otherwise: continue to question #2. Question #2: When would the code in the "else" block execute? If you don't know, it's ok to guess. If they answer "when a break didn't occur", I'm willing to give you, the asker, up to 100 lines of patch code in whatever python project you want.. If they answer "maybe when the for loop didn't run or was an empty list" then you don't owe me anything.

Head on over to graphine.org- I'm getting requests for database-backed graphs and don't know enough to do it portably. I asked 4 and got 2 correct answers, but I'm happy with the promised 100 lines. If you know as little about databases as I do, take a look at the graphml code- it's out of date and probably doesn't work. Geremy Condra

On Thu, 1 Oct 2009 09:00:21 pm Antti Rasinen wrote:

To add further insult to the naming injury, the else branch suffers from the fact that 99.9% of the time, the for-loop contains an if:

Really? You've done a statistically significant survey of code in the wild and come to a figure accurate to one part in a thousand? Not just plucked a number straight out of thin air? In my code, the figure is more like 20-40%. Choosing one representative module at random, only one in three for-loops include an if inside the loop. And when I use for...else, it's closer to 10%.

for x in xs: if cond(x): break # stuff else: # more stuff

My code pattern matching algorithm reads that as an indentation error. An else matches if so many times more often that decoding for..else requires unnecessary effort.

But then there are these: for x in xs: if cond(x): process() else: process_differently() else: do_something_else() for x in xs: process() else: do_something_else() They don't look anything like an indentation error to me. -- Steven D'Aprano

On Fri, 2 Oct 2009 01:23:27 pm Robert Kern wrote:

...

for x in xs: if cond(x): process() else: process_differently() else: do_something_else()

for x in xs: process() else: do_something_else()

They don't look anything like an indentation error to me.

Am I missing something? Since those examples don't have any break statements in them, why do you use an else:?

My bad -- process and process_differently are meant to stand in for a *block*, presumably including a break, not just a function call. I was attempting to show the indent structure. I shouldn't have included the parentheses, which just muddied the water. -- Steven D'Aprano

I also find for:… else: unintuitive. I know if has something to do with break, but I always forget if it means "there was no break" or "there was a break." I support the following change: for item in items: suite else: #Same as before, executes only if there was no break for item in items: suite else not break: #Executes only if there was no break. #PEP-8 should deprecate the bare else in favor of this. for item in items: suite else break: #Executes only if there was a break for item in items: suite else None: #None is a keyword now, so why not? #Executes only if there were no items or in while-loops the condition is never true I think the latter two language changes would be welcome additions to Python regardless of whether for-else stays the same in the ordinary case of not. Yes, there are ways of telling if the loop never broke or never ran the suite besides adding these grammar changes, but so what? This a fairly common pattern, and I think it would improve readability without hampering the programmer's mental model of Python any more than the existing for-else does today. If anything, this would hamper the mental model *less*. Two-cents-ly-yours, —Carl M. Johnson

On Fri, Oct 2, 2009 at 2:14 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

Encouraging people to refer to the idiom as "break/else" and including a SyntaxWarning for dubious usage of loop else clauses (i.e. those without an associated break statement) are probably two fairly low cost educational steps that could be taken though.

A SyntaxError would be more fitting for py4k but it's still not gonna make the for..else code readable. Asking people to call this construct a "break/else" is confusing because: 1. "break/else" insinuates the "else" block is for when a break statement _did_ occur. 2. the "else" is located immediately after the "for" block. Calling this anything but "for..else" is going to cause a tongue-twisting, mind boggling Stroop effect. IMHO the only way to avoid this is to rename/modify "else" to somehow convey it's relation to the break statement.

Steven D'Aprano wrote:

And in fact, it is legal to have for loops without a break but include an else. Is it useful? I don't know, but Python can't forbid them without breaking (pun not intended) code like this:

for x in xs: if __debug__: break else: print "whatever"

"if __debug__: suite" is special: the Python compiler optimizes the entire suite away when running with the -O flag. So if Python would treat the presence of an else as an error unless there was a break, you could have some code which was, or wasn't, legal according to the presence of the optimize flag. This is clearly a Bad Thing.

Hence, even if for...else with no breaks are useless, they must be allowed.

A SyntaxWarning should still be OK though - having an else clause that can only be reached in debug mode is pretty dubious in its own right. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Ron Adam wrote:

How about this?

try: for x in xs: foo() esle: Print "foo didn't raise an exception." except: print "foo riased an exception"

Using exceptions for flow control is very common in python.

The else is adding no value here. That example would be better written as: try: for x in xs: foo() print "foo didn't raise an exception." except: print "foo riased an exception"

Or this:

for x in xs: y = foo() if y is True: return else: Print "y was never True"

This is perfectly acceptable in my opinion.

Again, using else here is redundant and misleading. The code is clearer if it is left out entirely: for x in xs: y = foo() if y is True: return print "y was never True" The *only* time an else clause is a better alternative to just writing the code after the loop is when there is a break statement present that may skip over it. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Nick Coghlan wrote:

Ron Adam wrote:

...

How about this?

try: for x in xs: foo() esle: Print "foo didn't raise an exception." except: print "foo riased an exception"

Using exceptions for flow control is very common in python.

The else is adding no value here. That example would be better written as:

try: for x in xs: foo() print "foo didn't raise an exception." except: print "foo riased an exception"

...

Or this:

for x in xs: y = foo() if y is True: return else: Print "y was never True"

This is perfectly acceptable in my opinion.

Again, using else here is redundant and misleading. The code is clearer if it is left out entirely:

for x in xs: y = foo() if y is True: return print "y was never True"

The *only* time an else clause is a better alternative to just writing the code after the loop is when there is a break statement present that may skip over it.

All good points. I need another cup of coffee. ;-) There may be some obscure exception to the break-else pattern but I can't think of any at the moment. Considering the following...

...

...

break File "<stdin>", line 1 SyntaxError: 'break' outside loop

Documenting for/break/else patterns seems very appropriate. +1 I suppose that it would have been clearer if it was for/then and while/then. With a break stopping the loop, and skipping over the then block. While it's much easer to explain that way, It adds a new keyword and isn't something we could or should change now I suppose. Cheers, Ron

Stephen J. Turnbull wrote:

Ron Adam writes:

...

All good points. I need another cup of coffee. ;-)

There may be some obscure exception to the break-else pattern but I can't think of any at the moment.

May I suggest reading my posts. I've made at least two attempts at obscure exceptions and been corrected within minutes every time. At least you can avoid those! :-)

I'm not even going to try. :-) I looked at the grammer for each of the items in question and am wondering if that could be improved in any way so that they indicate how break and continue are used in loops. Here's the current grammer for Python 3.0 loops. Break and Continue are next to each other but no where near for and while in the documentation. while_stmt ::= "while" expression ":" suite ["else" ":" suite] for_stmt ::= "for" target_list "in" expression_list ":" suite ["else" ":" suite] break_stmt ::= "break" continue_stmt ::= "continue" Cheers, Ron

Why single out for/while and leave out try? It supports an else statement in a similar fashion. Honestly I think the syntax is fine as it is. Once I grasped what it did and why, I exploited it to great effect. The syntax may be unfamiliar to programmers coming from other languages, but so what? The same can be said of every language on the planet. (I felt like an idiot when I started to learn Haskell). FWIW, nothing in life is intuitive. Absolutely nothing. Everything has to be learned, even the simplest things. A baby has to learn how to nurse and many struggle with that unintuitive process as well. The concept of what is "intuitive" is entirely in the eye of the beholder and is effectively a non-concept. -1. On Wed, Sep 30, 2009 at 9:58 PM, Yuvgoog Greenle <ubershmekel@gmail.com> wrote:

I wouldn't modify the way for/else behaves btw. I would either: 1. rename the "else" to something else for "for" and "while" loops 2. remove the syntax altogether. 2to3 or 3to4 can do this by changing a boolean before the "break" statement for example.

...

expectations of those unwilling to learn the language

I can tell you I love python and of course many newcomers will/do too. I'm just noting that this might be a pimple worth popping.

One more thing, I have to clear django's name as it doesn't have a for/else construct, it has a for/empty construct that was inspired by a popular for/else django template recipe entitled:

...

"for" template tag with support for "else" if array is empty

(thanks for pointing that out Karen) On Thu, Oct 1, 2009 at 4:35 AM, alex23 <wuwei23@gmail.com> wrote:

...

On Oct 1, 11:07 am, Yuvgoog Greenle <ubershme...@gmail.com> wrote:

...

To make things worse, it's not that newcomers will say "hmm, what does this for/else thing do? lets look at the manual", they will mistakenly assume they understand what the construct means.

-1 for modifying Python to meet the "intuitive" expectations of those unwilling to learn the language. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Gerald Britton

Yuvgoog Greenle writes:

I wouldn't modify the way for/else behaves btw. I would either:1. rename the "else" to something else for "for" and "while" loops

If you prefer some existing keyword, -0.75, else -1. Note: As a native speaker, since "for ... else" isn't English, I would certainly look up the semantics before using the syntax. This is very probably true for Japanese as well, who are far better at (consciously) remembering English syntax than native speakers are. I don't know about other non-natives.

2. remove the syntax altogether.

-1. It's occasionally useful, and when it is, it's nice and concise.

Thank god for empirical evidence and thanks Antti for the measurement. This construct should have been named "finally", "didnt_break" or "not break": while self.more_points_to_check(): if self.found_it(): # Found the desired point breaknot break: # Exhausted the search space :( On Thu, Oct 1, 2009 at 2:00 PM, Antti Rasinen <ars@iki.fi> wrote:

...

Yuvgoog Greenle schrieb:

...

On python-dev the subject of for/else statements came up, so I had to mention how "ambiguous" the syntax seems to me. By "ambiguous" I meant that it's not obvious what should happen in the for/else and while/else constructs (the except/else construct is readable and great imo btw).

Even though it's documented, for me it's a bad construct because it can and will always be misinterpreted by a non-trivial amount of people seeing it for the first time. It's unreadable and confusing because the "else" isn't referring to the "for" it's in reference to the "break". The construct is only useful in loops with "break" statements, so in pseudo code or human the "else" would have probably been translated to "if didn't break".

I agree that the "else" clause is somewhat unintuitive. However, it has its uses and can often replace more awkward constructs. As such, I would be -1 on removing it, and -3 on reusing the else clause for some other purpose.

I must say that calling for ... else "somewhat unintuitive" is the understatement of the year. The analogy with if ... else leads further astray than Odysseus.

The feature itself is not bad. It's just that it is misnamed.

I did a quick poll at the office and at IRC, five people in total, with 2-8 years of Python experience. Two had never heard of the for..else -construct; one had heard that it exists and two know about it but have never used it. Three uninitiated, in other words.

All three gave similar replies: if the loop is not executed or the variable is not iterable, then the else-branch is executed. Here are their reactions, when they learned how it really works:

* "It should be called for..then" (or for..finally) * "WHAT. No f** way. Completely unintuitive" * "I'd hate whoever wrote that code"

These people are actual Python developers, not some newbies. And I completely agree with them. I've only once seen for...else in the wild and never used it myself.

To add further insult to the naming injury, the else branch suffers from the fact that 99.9% of the time, the for-loop contains an if:

for x in xs: if cond(x): break # stuff else: # more stuff

My code pattern matching algorithm reads that as an indentation error. An else matches if so many times more often that decoding for..else requires unnecessary effort.

I don't want the feature to be removed or even renamed (at least before Python 4). But the feature *is* badly named and unintuitive.

-- [ Antti Rasinen <*> ars@iki.fi ]

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Yuvgoog Greenle wrote:

This construct should have been named "finally", "didnt_break" or "not break":

"finally" would be at least as confusing as "else", since by analogy with try-finally it suggests that it will *always* be executed, which isn't the case. -- Greg

On Thu, 8 Oct 2009 12:10:00 am Gerald Britton wrote:

Are you sure? Under what conditions would the "finally" clause be bypassed?

Are you talking about the existing try...finally clause, or the hypothetical "let's rename for...else to for...finally" clause? If the second, then it would be bypassed under exactly the same conditions as the else in for...else is bypassed. E.g.: for x in [1, 2, 3]: raise Exception else: print "This is never printed" def test(): for x in [1, 2, 3]: return x else: print "This is never printed" Renaming 'for...else' to 'for...finally' doesn't turn it into a try block. The semantics remain the same. -- Steven D'Aprano

That's what I was getting at. As long as Python doesn't crash or the process is not killed by some external force (e.g. power failure), the finally clause of a try/except/finally will always be executed. On Wed, Oct 7, 2009 at 10:18 AM, Masklinn <masklinn@masklinn.net> wrote:

On 2 Oct 2009, at 03:35 , Greg Ewing wrote:

...

Yuvgoog Greenle wrote:

...

This construct should have been named "finally", "didnt_break" or "not break":

"finally" would be at least as confusing as "else", since by analogy with try-finally it suggests that it will *always* be executed, which isn't the case.

Then again, a try's finally isn't *always* executed. It's *almost always* executed, but if the runtime (or just the thread the block is in) crashes, is killed with kill -9 or the machine is shut down, it won't be.

Interestingly, because sys.exit throws an exception instead of killing the runtime, the finally block does run if you call sys.exit in the try block (in Java, it doesn't) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Gerald Britton

2009/10/1 Antti Rasinen <ars@iki.fi>:

I must say that calling for ... else "somewhat unintuitive" is the understatement of the year. The analogy with if ... else leads further astray than Odysseus.

The feature itself is not bad. It's just that it is misnamed. [...] I don't want the feature to be removed or even renamed (at least before Python 4). But the feature *is* badly named and unintuitive.

I agree. I use it from time to time and I used to have to look up the docs every time, because I couldn't remember wheteher the 'else:' clause meant 'if did break' or 'if didn't break'. I solved this problem by stopping thinking about it as while-else or for-else, but rather as break-else. -- Arnaud

On Thu, Oct 1, 2009 at 4:00 AM, Antti Rasinen <ars@iki.fi> wrote:

I must say that calling for ... else "somewhat unintuitive" is the understatement of the year.

"The nipple is the only thing that's intuitive. Everything else is learned." -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Thu, Oct 01, 2009 at 07:47:37AM -0700, Guido van Rossum wrote:

On Thu, Oct 1, 2009 at 4:00 AM, Antti Rasinen <ars@iki.fi> wrote:

...

I must say that calling for ... else "somewhat unintuitive" is the understatement of the year.

"The nipple is the only thing that's intuitive. Everything else is learned."

"There is no intuitive interface, not even the nipple. It's all learned." http://www.greenend.org.uk/rjk/2002/08/nipple.html Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

Let me rephrase - for..else is a _misleading_ construct. It suggests one thing yet does another. This response is way too long, so here's a TOC: 1. The Question Challenge - A way to examine if "for..else" is just unintuitive or misleading. 2. What can be done about for...else. 3. Lets talk about "try/else" because a few people mentioned it as though it's somehow related to the discussion. ---------------- 1. The Question Challenge - A way to examine if "for..else" is just unintuitive or misleading. Antti's experiment got me asking, you can try this as well. Ask a person who knows python the following questions: Question #1: Do you know what happens when an "else" appears after a "for" loop? if they answer yes then say nevermind. otherwise: continue to question #2. Question #2: When would the code in the "else" block execute? If you don't know, it's ok to guess. If they answer "when a break didn't occur", I'm willing to give you, the asker, up to 100 lines of patch code in whatever python project you want.. If they answer "maybe when the for loop didn't run or was an empty list" then you don't owe me anything. ------------- 2. What can be done about for...else. 1. Not allowing a for loop that has no "break" to have an "else". Just like "else" isn't allowed when there isn't an "except" in the "try". There really is no excuse, justification or sense in a "for" loop that has no "break" yet has an "else". 2. Lets not talk about removing the "else" from for/while completely since it does have its fans and cute use cases. 3. Renaming this construct for py4k wouldn't be too crazy if you use the existing reserved words "not" and "break". Look at this code and please note that it doesn't need any comments to make it readable (as opposed to Nick's example, no offence): for item in list_of_stuff: if item.is_awesome(): break not break: print("nothing is awesome :(") And I can even think of a few use cases for having just "break:". This block would execute only upon "break" occurring. That way you could have loops like this: for item in list_of_stuff: if item.is_awesome(): break break: celebrate(list_of_stuff) -------------------------- 3. Lets talk about "try/else" because a few people mentioned it as though it's somehow related to the discussion. "try/else" now _that_ is a red herring. There is no "try/else". OTOH "except/else", as I said before, is a beautiful, pythonic, useful and cool construct. This is the evidence:

...

...

try: ... print(1) ... else: File "<stdin>", line 3 else: ^ SyntaxError: invalid syntax try: ... print(2) ... finally: ... print(3) ... else: File "<stdin>", line 5 else: ^ try: ... print(7) ... except Exception as e: ... print(13) ... else: ... print(6) ... 7 6

Yuvgoog Greenle writes:

1. Not allowing a for loop that has no "break" to have an "else". Just like "else" isn't allowed when there isn't an "except" in the "try". There really is no excuse, justification or sense in a "for" loop that has no "break" yet has an "else".

+1. File an RFE against PyLint for sure, and against Python too. That's a *great* idea! Bikeshedding follows.

Antti's experiment got me asking, you can try this as well. Ask a person who knows python the following questions: Question #1: Do you know what happens when an "else" appears after a "for" loop? if they answer yes then say nevermind.

Er, no. It's more important if what people "know" is wrong than if naive guesses are wrong.

otherwise: continue to question #2. Question #2: When would the code in the "else" block execute? If you don't know, it's ok to guess.

I would fire a programmer who gave an answer.<0.5 wink> He might do the same in his own code or in a review of someone else's.

3. Renaming this construct for py4k wouldn't be too crazy if you use the existing reserved words "not" and "break". Look at this code and please note that it doesn't need any comments to make it readable (as opposed to Nick's example, no offence):

Nick's example is far more readable IMO. No offense. I can tell you why, too. In his example, the "else" is immediately preceded by the "if ... break" suite. Because "break" can only happen once in a loop, I read the else as the alternative to breaking out. Sloppy, yes, but since this is the common idiom using for-else, it works for me. :-) OTOH, "break" is an imperative; "not break" looks like a prohibition to me, not the target of a branch. You could use "for: ... if not break:" but that looks ugly to me, and worse requires several tokens of lookahead to disambiguate from an ordinary if block. I'll leave it up to GvR to decide whether for-else is "less Pythonic" than try-except-else.

And I can even think of a few use cases for having just "break:". This block would execute only upon "break" occurring. That way you could have loops like this:

for item in list_of_stuff: if item.is_awesome(): break break: celebrate(list_of_stuff)

You'd need multiple breaks for this to make sense. Else: for item in list_of_stuff: if item.is_awesome(): celebrate(list_of_stuff) break Some people think that having multiple breaks is bad style.

Nonsense - there are several other ways to break out of a loop. Raising an exception or returning for example

I do appreciate your response. I'd like you to examine how the "else" in question isn't relevant to the discussion of return or raise:

...

...

for i in range(10): ... print(1/0) ... else: ... print(100) ... Traceback (most recent call last): File "<stdin>", line 2, in <module> ZeroDivisionError: int division or modulo by zero

def eggs(): ... for i in range(10): ... return 1234 ... else: ... print(69) ... eggs() 1234

I think I understand what you're saying and I just don't understand how it pertains to for..else. Specifically I would like an explanation about why the following quote is nonsense to you. 2009/10/2 Stephen J. Turnbull <stephen@xemacs.org> Yuvgoog Greenle writes:

...

1. Not allowing a for loop that has no "break" to have an "else". Just like "else" isn't allowed when there isn't an "except" in the "try". There really is no excuse, justification or sense in a "for" loop that has no "break" yet has an "else".

+1. File an RFE against PyLint for sure, and against Python too. That's a *great* idea!

I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement: for i, j in enumerate(something): # suite i += 1 else: i = 0 # i == number of things processed The thing here is, "i" won't be set by the "for" statement if "something" is empty. OTOH, if "something" is non-empty, i >= 1 at the end of the for-loop. Using the "else" clause in this way ensure that "i" has the number of things processed at the end of the loop. To do this without the "else" I have to: i = 0 for i, j in enumerate(something): # suite i += 1 I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement: for i, j in enumerate(something): # suite i += 1 else: i = 0 # i == number of things processed Does it work? Sure! But it moves the setting of "i" outside the for-construct, which I personally dislike. On Fri, Oct 2, 2009 at 8:58 AM, Michael Foord <fuzzyman@gmail.com> wrote:

2009/10/2 Yuvgoog Greenle <ubershmekel@gmail.com>

...

I think I understand what you're saying and I just don't understand how it pertains to for..else. Specifically I would like an explanation about why the following quote is nonsense to you.

Hmm... on consideration, breaking out of a loop without a break (i.e. exception or return) wouldn't enter the else clause *anyway*, so there is still no need for the else clause.

My apologies, I retract. :-)

Michael

...

...

2009/10/2 Stephen J. Turnbull <stephen@xemacs.org>

Yuvgoog Greenle writes:

 > 1. Not allowing a for loop that has no "break" to have an "else". Just like  > "else" isn't allowed when there isn't an "except" in the "try". There really  > is no excuse, justification or sense in a "for" loop that has no "break" yet  > has an "else".

+1.  File an RFE against PyLint for sure, and against Python too. That's a *great* idea!

-- http://www.ironpythoninaction.com/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Gerald Britton

Nope:

...

...

l = [] for i,j in enumerate(l): pass ... i Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'i' is not defined

"i" is not initialized if "l" is empty. On Fri, Oct 2, 2009 at 9:54 AM, Yuvgoog Greenle <ubershmekel@gmail.com> wrote:

On Fri, Oct 2, 2009 at 4:46 PM, Gerald Britton <gerald.britton@gmail.com> wrote:

...

I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement:

for i, j in enumerate(something):  # suite  i += 1 else:  i = 0

# i == number of things processed

Sorry, there must be some typo in your code. The "i" is always 0 after the loop unless you break.

...

...

...

for i, j in enumerate(range(10)): ...     i +=1 ... else: ...     i = 0 ... i 0

Also, why would one increment the enumeration index "i" by hand?

-- Gerald Britton

Those who believe that the for/else construct is sufficiently clear, please read this email again: Gerald Britton:

I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement:

for i, j in enumerate(something):  # suite  i += 1 else:  i = 0

# i == number of things processed

The thing here is, "i" won't be set by the "for" statement if "something" is empty.  OTOH, if "something" is non-empty, i >= 1 at the end of the for-loop.  Using the "else" clause in this way ensure that "i" has the number of things processed at the end of the loop.

To do this without the "else" I have to:

i = 0 for i, j in enumerate(something):  # suite  i += 1 I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement:

for i, j in enumerate(something):  # suite  i += 1 else:  i = 0

# i == number of things processed

Does it work?  Sure!  But it moves the setting of "i" outside the for-construct, which I personally dislike.

I don't mean to pick on Gerald, but he got the meaning of for/else dead wrong *in the middle of a debate about for/else*. This shows that even experienced Pythoneers who read Python-ideas can be confused about the meaning of for/else. Using it in production code means leaving a trap for the programmers who come after you and read your code to get confused and create a bug. Yes, when the others turn your working use of for/else into a bug, it's their fault for not reading the tutorial more closely so as not get confused by it, but ultimately no matter how much you blame the user, that won't stop the next guy who uses your code from misunderstanding it. The best solution to this inherent confusingness is to leave bare for/else alone for the foreseeable future, but to add a less confusing synonym for this feature. I propose "else not break:" although "elif not break:" is good too. Rewriting Gerald's example as for i, j in enumerate(something): # suite i += 1 else if not break: i = 0 # i == number of things processed makes it 100% smack you in the face obvious that "Oh yeah, this is going to set i to 0 every time, since there's no break." In an unrelated but also good idea, it would be nice to be able to do what Gerald thought he was doing: for i, j in enumerate(something): # suite i += 1 else if None: #or some other suitable phrase for "empty" i = 0 # i == number of things processed — Carl

Steven D'Aprano:

You can already do this today, with no change to the compiler, using only a slightly different syntax to that suggested:

for i, j in enumerate(something):    # suite    i += 1 else:  # if not break    i = 0

Best of all, it's an extensible syntax, so there's no need for bike-shedding arguments about whether it should be spelled "not break" or "no break" or "didn't break" or "only if loop ended normally". All of these variants, and more, are accepted:

Hoisted by my own petard! :-D This was also my suggestion for adding a do-while to Python a few weeks back: while True: #do { stuff # } until { if cond: break # } — Carl

Sory Carl, I did NOT get it dead wrong. The else is executed if the for loop falls through. That's the whole idea. Probably I should have set i to -1 in the else clause of the toy example though: for i, j in enumerate(something): # do something i += 1 else: i = -1 if i > 0: # we did something If you don't think the else is executed when the for-loop falls through, then you should re-read the documentation, here: http://docs.python.org/reference/compound_stmts.html#the-for-statement Where it says (just as I did, but in other words): "When the items are exhausted (which is immediately when the sequence is empty), the suite in the else clause, if present, is executed, and the loop terminates." On Fri, Oct 2, 2009 at 9:18 PM, Carl Johnson <cmjohnson.mailinglist@gmail.com> wrote:

Those who believe that the for/else construct is sufficiently clear, please read this email again:

Gerald Britton:

...

I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement:

for i, j in enumerate(something):  # suite  i += 1 else:  i = 0

# i == number of things processed

The thing here is, "i" won't be set by the "for" statement if "something" is empty.  OTOH, if "something" is non-empty, i >= 1 at the end of the for-loop.  Using the "else" clause in this way ensure that "i" has the number of things processed at the end of the loop.

To do this without the "else" I have to:

i = 0 for i, j in enumerate(something):  # suite  i += 1 I can't imagine why I'm still commenting on this thread, since there is no chance that Python will remove the "else" from for/while or put conditions on it, but here is an example of a use that has no break statement:

for i, j in enumerate(something):  # suite  i += 1 else:  i = 0

# i == number of things processed

Does it work?  Sure!  But it moves the setting of "i" outside the for-construct, which I personally dislike.

I don't mean to pick on Gerald, but he got the meaning of for/else dead wrong *in the middle of a debate about for/else*. This shows that even experienced Pythoneers who read Python-ideas can be confused about the meaning of for/else. Using it in production code means leaving a trap for the programmers who come after you and read your code to get confused and create a bug. Yes, when the others turn your working use of for/else into a bug, it's their fault for not reading the tutorial more closely so as not get confused by it, but ultimately no matter how much you blame the user, that won't stop the next guy who uses your code from misunderstanding it.

The best solution to this inherent confusingness is to leave bare for/else alone for the foreseeable future, but to add a less confusing synonym for this feature. I propose "else not break:" although "elif not break:" is good too. Rewriting Gerald's example as

for i, j in enumerate(something):  # suite  i += 1 else if not break:  i = 0

# i == number of things processed

makes it 100% smack you in the face obvious that "Oh yeah, this is going to set i to 0 every time, since there's no break."

In an unrelated but also good idea, it would be nice to be able to do what Gerald thought he was doing:

for i, j in enumerate(something):  # suite  i += 1 else if None: #or some other suitable phrase for "empty"  i = 0

# i == number of things processed

— Carl _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Gerald Britton

Yes, quite right. Another way would be: for i, j in enumerate(x): # do something i += 1 else: if "i" not in vars(): i = 0 Is it better than initializing before? Not sure. I guess it's a matter of taste. On Sat, Oct 3, 2009 at 11:22 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

Gerald Britton wrote:

...

Sory Carl, I did NOT get it dead wrong.  The else is executed if the for loop falls through.  That's the whole idea.  Probably I should have set i to -1 in the else clause of the toy example though:

for i, j in enumerate(something):   # do something   i += 1 else:  i = -1

if i > 0:   # we did something

If you don't think the else is executed when the for-loop falls through, then you should re-read the documentation, here:

http://docs.python.org/reference/compound_stmts.html#the-for-statement

Where it says (just as I did, but in other words):

"When the items are exhausted (which is immediately when the sequence is empty), the suite in the else clause, if present, is executed, and the loop terminates."

The code in your example is semantically identical to the following:

 for i, j in enumerate(something):    # do something    i += 1  i = -1

 if i > 0:    # This block is unreachable...

Without a break statement in the body of the loop the else will by executed unconditionally, hence it is exactly the same as if the code it contains was just inline after the loop body.

The semantics you describe can be obtained only by initialising i before the loop:

 i = -1  for i, j in enumerate(something):    # do something    i += 1

 if i >= 0:    # We did something

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia ---------------------------------------------------------------

-- Gerald Britton

On 3 Oct 2009, at 13:49 , Gerald Britton wrote:

Sory Carl, I did NOT get it dead wrong. The else is executed if the for loop falls through. That's the whole idea. Probably I should have set i to -1 in the else clause of the toy example though:

for i, j in enumerate(something): # do something i += 1 else: i = -1

if i > 0: # we did something

If you don't think the else is executed when the for-loop falls through, then you should re-read the documentation, here: Carl didn't dispute that point. In fact that's exactly the issue with your code: since you don't have any `break` statement in your `for:` loop, the `else:` clause will *always* be executed, whether `something` is an empty collection or not.

Thus, the following `if i > 0:` clause cannot under any circumstance be executed. Your code (unless there is a break in the 'do something' part) is equivalent to: for i, j in enumerate(something): # do something i += 1 i = -1 if i > 0: # can never happen

Gerald Britton writes:

Sory Carl, I did NOT get it dead wrong. The else is executed if the for loop falls through.

for i, j in enumerate(something): # do something i += 1 else: i = -1

Carl's point (revised to correspond to the new example) is assert(i == -1) so

if i > 0: # we did something

is dead code.

Stephen J. Turnbull wrote:

Yuvgoog Greenle writes:

...

I think I understand what you're saying and I just don't understand how it pertains to for..else. Specifically I would like an explanation about why the following quote is nonsense to you.

I didn't say it was nonsense and I didn't mean it was nonsense.

I can see no reason at all why PyLint wouldn't warn about "breakless for-else". "raise StopIteration" and "if __debug__: break" *may* be sufficient reason Python itself shouldn't be too noisy, but for sure PyLint should warn about it.

raise StopIteration in the body of the for loop will escape, just like any other suggestion. However, Gerald's point that the else clause can also be used to give the iteration variable a "default" value (with nary a break in sight) in addition to the more traditional search loop idiom is enough to convince me that the compiler should stay out of this one. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Footnotes: [1]  StopIteration can, but I thought raising StopIteration in user code is considered quite bad form.

StopIteration once put forward on this very list as a way to stop a generator. e.g. def stop(): raise StopIteration gen = (x in something if <x meets some condition> or stop() ) Toy example: Say you want the squares of all natural numbers n such that n <= j. Here's one simple way using the stop function above: from itertools import count squares = (n**2 for n in count() if n <= j or stop() ) Without the "or stop()" the generator goes into an infinite loop when n exceeds 10. Of course you can do this toy example other ways, this is just an illustration.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Gerald Britton

Michael Foord wrote:

Nonsense - there are several other ways to break out of a loop. Raising an exception or returning for example.

But both of those bypass any code following the for-loop, so there is no need for an else-clause in those cases. -- Greg

On Fri, 2 Oct 2009 09:01:20 pm Nick Coghlan wrote:

Yuvgoog Greenle wrote:

...

1. Not allowing a for loop that has no "break" to have an "else". Just like "else" isn't allowed when there isn't an "except" in the "try". There really is no excuse, justification or sense in a "for" loop that has no "break" yet has an "else".

As Stephen said, that's a very good point. Having the compiler issue a SyntaxWarning when compiling such code is perfectly possible and would make a great deal of sense (and probably prevent many cases of naive misuse).

I disagree that it makes sense. Why raise a SyntaxWarning for legal code? Shall we raise SyntaxWarning for the following as well? #1 pass pass #2 if False: parrot() #3 for x in []: do_something() #4 try: something() except Exception: raise etc. There are all sorts of code which is legal but does nothing. Why should the language single out one of them for a warning? If that warning is anywhere, it should be in PyLint or equivalent. It's even more problematic when you consider code where the break is inside a "if __debug__" clause. Then you've code which raises a warning when you run with the -O flag, and doesn't when you run without. -- Steven D'Aprano

Nick Coghlan wrote:

Steven D'Aprano wrote:

...

On Fri, 2 Oct 2009 09:01:20 pm Nick Coghlan wrote:

...

Yuvgoog Greenle wrote:

...

1. Not allowing a for loop that has no "break" to have an "else". Just like "else" isn't allowed when there isn't an "except" in the "try". There really is no excuse, justification or sense in a "for" loop that has no "break" yet has an "else". As Stephen said, that's a very good point. Having the compiler issue a SyntaxWarning when compiling such code is perfectly possible and would make a great deal of sense (and probably prevent many cases of naive misuse). I disagree that it makes sense. Why raise a SyntaxWarning for legal code?

Yeah, I was wrong. Definitely in pylint/pychecker territory.

After the additional posts in the discussion, I'm back to my previous opinion - the construct should be referred to as break/else (or for/break/else and while/break/else) and we should at least investigate having the compiler itself raise at least a SyntaxWarning if it encounters a for/else or while/else construct without also encountering a break statement inside the loop. The situation is *exactly* analagous to try/except/else: if there is no except clause, then using the "else" is redundant - just put the code inside the try block (if there is also a finally clause) or ditch the try statement altogether (if there is no finally clause). The compiler enforces this by treating try/else with no except clause as a SyntaxError. For a loop with no break statements the else clause will *always* be executed, hence using the clause is completely redundant - the code it contains might as well be dedented and placed inline at the same level as the loop header. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Nick Coghlan wrote:

Nick Coghlan wrote:

For a loop with no break statements the else clause will *always* be executed, hence using the clause is completely redundant - the code it contains might as well be dedented and placed inline at the same level as the loop header.

The loop could have a "return", "raise", or be inside a "try/except" instead of having a "break". Cheers, Ron