Sorry, that does not convince me.
You're assuming that everybody is a language designer. Many Python users actually have little language design sense, and you shouldn't need to have it in order to be able to use the language. People are productive by learning to recognize and copy patterns, but their pattern recognition isn't guided by what you can reason out from thinking about how the implementation works.
An issue with except clauses in particular is that during normal execution they don't get executed, and hence they are often not tested carefully. (Witness the evergreen bug of having a typo in your exception logging code that takes down production.) In the case of the proposed except clause this will probably mean that people will add except clauses to for-loops because they've read somewhere "for-loops can now have an except clause" and never read the rest of the description, and then they'll add a non-functional except-clause to a for-loop, thinking they've solved a certain potential problem. So now future maintainers have two problems: the exception is not caught when it was meant to be caught, and there is a mysterious except-clause on the for-loop that nobody knows for sure why it was added.
I don't think there's a solution that solves the specific issue without confusing most people. Users of for-loops should probably do one of three things:
- Don't worry about exceptions in the iter() and next() calls.
- Put a try/except around the entire for-loop and don't worry about whether the exception came from an iter() or next() call or from the loop body.
- Rewrite things without a for-loop, like Serhiy showed in his first message. This is ugly but the need should be very rare.
On Mon, Jul 29, 2019 at 12:26 PM Dominik Vilsmeier dominik.vilsmeier@gmx.de wrote:
I think the focus shouldn't be on whether such syntax is possibly confusing or not because
a) People will always remember that's either one way or the other, but
are very unlikely to just assume one; hence they can always check what it
does, and more importantly,
b) It's actually pretty easy to remember which way it is, by just
considering that a syntax feature exists for scenarios that can't be easily
solved otherwise. For for ... else it's actually more tricky than for the
proposed syntax because that doesn't let you distinguish between "else is
only executed if the loop didn't break" and "else is only
executed if
the loop didn't execute at all". But for for ... except or while ...
except it will be even more obvious because try ... excepting the
body
is just as easy as, well, try ... excepting the body; it's pretty clear
that no new syntax would be required for that and hence it must concern the
statement itself since that's not easy to work around.
The only possible confusion I see is when people look at something like this:
for ...:
LENGTHY BODY
except ...:
HANDLER
else:
SOMETHING_ELSE
and only look at the except ... else part and readily assume that the
two are complementary. But that's easy to prevent by only allowing the
opposite order, i.e. for ... else ... except, stressing that the two are
unrelated in this case.
In the end a feature should be driven by its usefulness to the community
and whether it provides a solution for an otherwise (hard|awkward)-to-solve
problem. I could imagine that due to the awkward workaround, especially
regarding with, corresponding "self-made" code is either error-prone or
people will not even try to work around it in the first place. This feature
will probably be among the less prominent ones, but someone who needs it
will be glad that it exists and they're also likely to be well aware of
what it does (just like with for ... else). Someone who encounters that
feature for the first time, e.g. when reviewing some code, will probably
check what it does and even if not, the assumption that it excepts the
whole body should be perplexing since (a) excepting whole blocks by default
is not really best practice and (b) it's pretty easy to accomplish that
with existing syntax.
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/JIHFJT... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him/his **(why is my pronoun here?) http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...