On Fri, Feb 28, 2014 at 6:38 PM, Glenn Linderman <v+python@g.nevcal.com> wrote:
Whereas the current PEP syntax has ambiguity regarding how to interpret
a-expr except except-list-b: b-expr except except-list-c: c-expr (does the
2nd except apply to a-expr or b-expr?), without parentheses, and, as far as
I am concerned, even with the parentheses, this syntax makes it very clear
that each of the Exception-lists apply to a-expr.
Fair enough. It's a bit hard to talk about multiple except
expressions, though, as they're a problem unless formally supported -
and they're almost never needed. Really, all you need to do is say
"never abut except-expressions without parentheses" (which the current
proposal and the "parens around the exception bit only" proposal both
enforce), and then there's no problem. I expect that normal use of
this won't include any form of chaining. Yes, it can - like any
feature - be used abnormally, but at some point it's better to just
drop it out as a statement.
Key advantage to others may be that because the : is within the () [and the
leading ( is quite nearby, making it obvious], it is less likely to be
considered a statement boundary, and more easily explained as a special type
of list syntax... not _really_ a list, because it is really code to be
executed somewhat sequentially rather than data, and lists don't have : ...
and not _really_ a dict constant, which does have :, because the Exception
is not _really_ a key, but the syntax can draw on analogies with the dict
constant syntax which will help people remember it, and even sort of
understand that there is a pair-wise relationship between the Exception-list
and the expression after the :, without repeating the except over and over.
See the confusing terminology we have here? It might be called a
"list" of except-expressions, but the brackets are round, and a list's
are square. It's kinda like dict syntax, only again, the other sort of
bracket, and it's wrong to try to construct a dict; it'd be too
tempting to conflate this with some of the other current proposals for
lazily-evaluated expressions (aka "simpler syntax for lambda" or other
terms). This is, fundamentally, a multi-part expression on par with
"and" and "or": first, evaluate the primary expression; then, if an
exception is raised, evaluate the exception list and see if it
matches; then, if it matches, squash the exception and evaluate the
default expression. You can't turn that into a dict, partly because
you'd need to sort out lazy evaluation, and partly because a dict is
unordered - if this is expanded to support multiple except clauses,
they have to be processed in order. (You might, for instance, catch
ZeroDivisionError, and then Exception, with different handling. It'd
be VERY confusing for them to be processed in the wrong order,
particularly if it happens unpredictably.)