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

[Nick Coghlan]

On 28 February 2014 21:46, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, Feb 28, 2014 at 8:30 PM, Glenn Linderman <v+python at g.nevcal.com> wrote:
>> > Are there any other expressions that allow parens around a part of the
>> > expression, without the stuff inside them becoming a completely
>> > separate sub-expression?
>>
>> Sure. Function invocation.  You can claim (and it is accurate) that the
>> stuff inside is somewhat independent of the actual function called, but the
>> syntax is  function-name open-paren parameter-list close-paren, and the
>> stuff in the parens would be a tuple if it were purely data, except not
>> quite a tuple because some items are pairs (name and value), but it winds up
>> being neither a tuple, nor a list, nor a dict, but instead a complex
>> structure related to code execution :)
>
> Thanks, that's exactly the sort of example I was looking for :) For
> some reason I mentally blanked and didn't think of that. My point is,
> if you're going to look for parens around the bit after except, we
> should look at styling and layout that follows how that's done.

Also generator expressions and most uses of yield or yield from as
embedded expressions. Parentheses are our general "this next bit may
not be following the normal syntax rules" utility, in addition to
being used to override the normal precedence rules (square brackets
and curly braces similarly denote regions where the parsing rules may
differ from the top level ones).

As far as the specific problem I'm attacking with this variant of the
proposal goes, one of the recurring reactions from different people
has been "but colons are used to introduce suites, not expressions".
This impression is not, in fact, correct, as the colon is already used
as a subexpression separator in four cases:

* dict display key:value pairs
* slice notation start:stop:step triples
* function parameter : annotation separation
* lambda expression arg list : return value separation

PEP 463 just adds a fifth such case, as an exception spec:result separator.

The preferred notation in the PEP most resembles the existing lambda
use case, with "except" instead of "lambda", an exception handling
spec instead of an argument list and an additional leading expression:

    (expr except Exception: default)

Lots of people don't like the lambda notation though, so it isn't
necessarily a particularly compelling parallel to use. By contrast,
it's rare to hear any objections to the {key:value} dict display
syntax. Hence the proposed tweak to the syntax to define an "exception
handler expression" syntax that is analogous to a dict display rather
than a lambda expression:

    expr except (Exception: default)

However, I have realised that there *is* a major downside to that
notation, which is that it lacks the connotations of lazy evaluation
associated with lambda expressions, whereas the default result of an
except expression won't be evaluated at all if the exception isn't
thrown.

So I think that on balance, I actually do prefer your current
proposal. That said, I do think this is a variant worth discussing
explicitly in the PEP, if only to remind people that there's
definitely precedent for using a colon to separate two subexpressions
inside a larger expression element - it's not *just* used to introduce
suites, even though that is by far the most *common* use case.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia