On 25/07/2020 20:11, Christopher Barker wrote:
On Sat, Jul 25, 2020 at 4:39 AM Eric V. Smith <e...@trueblade.com
<mailto:e...@trueblade.com>> wrote:
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.
Naturally there is *less* benefit from improving something that is used
rarely than from improving something that is used often.
That doesn't mean *no* benefit, or that we shouldn't bother.
-CHB
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/SJJZZ5JVU77ACZSEDLSN7OORNPGIPLOT/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/YJZTFGWFFRIHQCNUK4SQ453ZMCOJDPEE/
Code of Conduct: http://python.org/psf/codeofconduct/