On Sat, Jul 25, 2020 at 4:39 AM Eric V. Smith <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.
-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/
