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:

1. Don't worry about exceptions in the iter() and next() calls.
2. 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.
3. 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 <> 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 ... except`ing the body is just as easy as, well, `try ... except`ing 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 ...:
    except ...:

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 `except`s 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 --
To unsubscribe send an email to
Message archived at
Code of Conduct:

--Guido van Rossum (
Pronouns: he/him/his (why is my pronoun here?)