<div dir="ltr">Let me rephrase - for..else is a _misleading_ construct. It suggests one thing yet does another.<div><br></div><div>This response is way too long, so here's a TOC:</div><div>1. The Question Challenge - A way to examine if "for..else" is just unintuitive or misleading.</div>
<div>2. What can be done about for...else.</div><div>3. Lets talk about "try/else" because a few people mentioned it as though it's somehow related to the discussion.</div><div><br></div><div>----------------</div>
<div>1. The Question Challenge - A way to examine if "for..else" is just unintuitive or misleading.</div><div><br></div><div>Antti's experiment got me asking, you can try this as well. Ask a person who knows python the following questions:</div>
<div>Question #1: Do you know what happens when an "else" appears after a "for" loop?</div><div>    if they answer yes then say nevermind.</div><div>    otherwise: continue to question #2.</div><div>Question #2: When would the code in the "else" block execute? If you don't know, it's ok to guess.</div>
<div>    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..</div><div>    If they answer "maybe when the for loop didn't run or was an empty list" then you don't owe me anything.</div>
<div><br></div><div>-------------</div><div>2. What can be done about for...else.</div><div><br></div><div>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".</div>
<div>2. Lets not talk about removing the "else" from for/while completely since it does have its fans and cute use cases.</div><div>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):</div>
<div><br></div><div>for item in list_of_stuff:</div><div>    if item.is_awesome():</div><div>        break</div><div>not break:</div><div>    print("nothing is awesome :(")</div><div><br></div><div>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:</div>
<div><br></div><div>for item in list_of_stuff:</div><div>    if item.is_awesome():</div><div>        break</div><div>break:</div><div>    celebrate(list_of_stuff)</div><div><br></div><div>--------------------------<br><div>
3. Lets talk about "try/else" because a few people mentioned it as though it's somehow related to the discussion.</div><div><br></div><div>"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.</div>
<div><br></div><div>This is the evidence:</div><div><br></div><div><div>>>> try:</div><div>...     print(1)</div><div>... else:</div><div>  File "<stdin>", line 3</div><div>    else:</div><div>       ^</div>
<div>SyntaxError: invalid syntax</div><div>>>> try:</div><div>...     print(2)</div><div>... finally:</div><div>...     print(3)</div><div>... else:</div><div>  File "<stdin>", line 5</div><div>    else:</div>
<div>       ^</div><div><div>>>> try:</div><div>...     print(7)</div><div>... except Exception as e:</div><div>...     print(13)</div><div>... else:</div><div>...     print(6)</div><div>...</div><div>7</div><div>
6</div></div></div><div><br></div></div></div>