[Python-Dev] PEP 463: Exception-catching expressions

Chris Angelico rosuav at gmail.com
Sat Feb 22 04:46:34 CET 2014

On Sat, Feb 22, 2014 at 9:06 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>> On 21 February 2014 13:15, Chris Angelico <rosuav at gmail.com> wrote:
>>> Generator expressions require parentheses, unless they would be
>>> strictly redundant.  Ambiguities with except expressions could be
>>> resolved in the same way, forcing nested except-in-except trees to be
>>> correctly parenthesized
>> I'd like to make the case that the PEP should adopt this as its
>> default position.
> I generally agree, but I'd like to point out that this
> doesn't necessarily mean making the parenthesizing rules as
> strict as they are for generator expressions.
> The starting point for genexps is that the parens are part of
> the syntax, the same way that square brackets are part of
> the syntax of a list comprehension; we only allow them to
> be omitted in very special circumstances.
> On the other hand, I don't think there's any harm in allowing
> an except expression to stand on its own when there is no
> risk of ambiguity, e.g.
>    foo = things[i] except IndexError: None
> should be allowed, just as we allow
>    x = a if b else c
> and don't require
>    x = (a if b else c)

I'm inclined to agree with you. I fought against the mandated parens
for a long time. Would be happy to un-mandate them, as long as there's
no way for there to be ambiguity. Is CPython able to make an operator
non-associative? That is, to allow these:

value = expr except Exception: default
value = (expr except Exception: default) except Exception: default
value = expr except Exception: (default except Exception: default)

but not this:

value = expr except Exception: default except Exception: default

? By effectively demanding parens any time two except-expressions
meet, we could leave the option open to read multiple clauses off a
single base exception. If that can be done, and if people's need for
clarity can be satisfied, and if the rules aren't too complicated, I'd
be happy to go back to "parens are optional".


More information about the Python-Dev mailing list