[Python-ideas] except expression

[Andrew Barnert]

From: Steven D'Aprano <steve at pearwood.info>

Sent: Wednesday, February 19, 2014 12:14 AM


> On Wed, Feb 19, 2014 at 06:06:05PM +1100, Chris Angelico wrote:
> 
> 
>>  Despite the numbers saying that 'as' is almost completely 
> unnecessary
>>  to the proposal, I'm leaving it in for the moment, pending more data.
>>  However, I'm removing two parts of the proposal: bare except clauses
>>  (use "except BaseException:" if you really want that) and 
> chaining of
>>  excepts (use parens, "(expr except Exception1: default1) except
>>  Exception2: default2").
> 
> 
> I think it will be helpful to include a section with a few definitions, 
> because the term "chaining" is ambiguous. It could mean either:
> 
> * Multiple except clauses in a single expression (that is, n-ary 
>   operator, for n > ). Example:
> 
>     (expression except SpamError: spam,
>                 except EggsError: eggs)
> 
> 
> where the 5 operands here are
> 
>     - expression
>     - SpamError
>     - EggsError
>     - spam
>     - eggs
> 
> 
> 
> Or chaining could mean wrapping one except-expression inside another, 
> such as:
> 
>     (expression except SpamError: spam) except EggsError: eggs
> 
> which has two expressions each with three operands:
> 
>     - expression
>     - SpamError
>     - spam
> 
> and
> 
>     - (expression except SpamError: spam)
>     - EggsError
>     - eggs
> 
> 
> I think it is important to decide which one is chaining, and which one 
> is not, include it in the PEP as a definition, and stick with it. I 
> *strongly* suggest that chaining means the second case. That's what 
> chaining means when we talk about method chaining:
> 
> obj.spam().eggs()  # call eggs method of the result returned by spam
> 
> and exception chaining:
> 
> raise ThisError from some_exception
> 
> I don't think that we should prohibit passing one except-expression as 
> argument to another.
> 
> The first case, the n-ary form, can be deferred for later. But I don't 
> think that's chaining.
> 
> It is also important to note that this are not, in general, the same 
> thing! 


I think it's better to just avoid the word "chaining" entirely in the PEP, for the same reason it's worth avoiding the n-ary form in the syntax.

The reason for banning the n-ary form is that it's ambiguous (to humans—obviously the parser could be trivially coded to pick one interpretation or the other) whether it's two excepts on a single try expression, or one except expression inside another. To some people the first interpretation seems like the obvious way to read it, the only one consistent with the rest of Python—but there have been people in this discussion who disagree, and surely that will be even more of a problem with novices. The fact that they are not the same thing _in general_, but _often_ have the same effect anyway, just increases the potential for confusion.

The term "chaining" is ambiguous in the same way. To many people who see the first interpretation, "chaining" obviously means the second one. But there are obviously people who disagree—including the author of the PEP—and surely that will again be even more of a problem with novices.

So, instead of introducing a potentially confusing term and then defining it, why not just avoid the term? Explain that the n-ary form with multiple except clauses is not allowed (for now); if you want that, _sometimes_ you can use an except expression inside another except expression, but sometimes you will have to rewrite your expression or use the statement form instead. The PEP could even give simple examples of when the substitution does and doesn't work.