On 7/25/2020 7:28 AM, Chris Angelico wrote:
> Do you REALLY think that everyone will automatically understand it
> just because it's spelled "for... then" instead of "for... else"?
I wouldn't find "for ... then" any less confusing than "for ... else". I
do find "for ... else if not break" easier to understand,
I'm pretty sure that the OP on this proposed "then" as a placeholder, with the final choice of word to be determined. But I do think this is pretty darn illustrative --'cause I would find "then" even LESS intuitive, and it's a whole new keyword to boot!
I'm one of those folks that have been around Python for a long time -- starting with 1.5 -- and I still find for-else a bit confusing, but I remember that it exists, so go figure it out when I need it. And that is not very often. Frankly, it's a nifty feature, but it's still not a very common use case -- so It's just not a very clear win to spell it better. And as the "then" example shows, it's really hard to find a better spelling -- it's just not that common a construct in programming languages, and it's not used that often in Python -- if it were, I"d probably remember what it meant :-)
but I'm not
convinced its worth the hassle over "for ... else # if not break". Four
keywords in a row!
well, there are two sides to usability:
1) Remembering it's there, and how to use it when you are writing code, which I think is not such a big deal -- if you remember its there, you can figure out how to use it. And if you don't remember it's there, then a better spelling isn't going to help.
2) understanding what it means when you are reading code -- and that, a better spelling would help with. But I don't get folks that would reject it in a code review -- I'd just suggest that you add a # if not break comment -- or better yet a comment that describes why it's there in the context of that problem -- as comments are supposed to do.
Would you really as someone to replace:
for dodad in all_the_things: if dodad == something_special:
found_special_dodad = True
break
do_things_with(dodad)
else: # the special one wasn't there -- need to process the stuff
process(stuff)
with this?:
found_special_dodad = False
for dodad in all_the_things:
if dodad == something_special:
found_special_dodad = True
break
do_things_with(dodad)
...
if not found_special_dodad:
# the special one wasn't there -- need to process the stuff
process(stuff)
The for--else construct exists for a reason: it's much cleaner than creating a flag and checking it later. Sure it would be nicer if it had a better spelling, but else # not break is pretty easy if you want to make your code more readable and there isn't need for an explanatory comment otherwise.
I'm not advocating for any change (Obviously :-) ) -- but if there were to be one, I"d strongly vote for some version of else not break or else if not break because it introduces no keywords, and it's a lot more compatible documentation-wise than a different word -- it's almost like a built-in commnet :-) By that I mean that folks that see the two different spellings in two different tutorials or SO answers ,or whatever, are more likely to realize that they mean the same thing.
But all of these always make me wonder about a return inside the suite.
Does the "else" part execute (answer: no). So as a rule, I avoid the
construct entirely,
really? does an if-else clause execute if there's a return in the if? no. why would this be any more confusing?
not that it comes up very often, anyway.
This is the really key point. I wanted to use a real code example above, but I could not remember when I'd ever used it -- and it's hard to search for, so I couldn't find one.
So: churn to make something rarely needed a little bit better -- I don't see the point.
-CHB