[Python-ideas] except expression

Chris Angelico rosuav at gmail.com
Sun Feb 16 04:57:12 CET 2014


On Sun, Feb 16, 2014 at 2:35 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sun, Feb 16, 2014 at 12:35:59AM +0000, MRAB wrote:
>> On 2014-02-15 23:46, Chris Angelico wrote:
>> >>>    things[i](except IndexError: 42)
>> >>
>> >I'm not liking the parenthesized version here, because the 'except'
>> >expression has to know how much of the preceding expression to modify.
>
> I don't think this is terribly different from the if-expression. The
> parser sees an expression:
>
>     1/x ...
>
> and doesn't know it is part of an if-expression until it has read on and
> seen the "if":
>
>     1/x if x != 0 ...
>
> so I don't expect this to be a problem.
>> >but not around the except clause:
>> >
>> >thing[i] (except IndexError: 42) # Nope
>> >1/x (if x else "Div by 0") # Nope
>
> I disagree about prohibiting this. I think it actually makes it easier
> to read in the case of multiple except terms.

The if/else version is currently an error, because the parens are
breaking the sequence up:

>>> 1/x (if x else "Div by 0")
SyntaxError: invalid syntax

(highlighting the "if" as the invalid part)

The way I understand it, the entire expression from 1/x to "Div by 0"
has to be parsed as a unit. Putting parens around part of it breaks
that. The same goes for the exception-catching version, unless the
parens are specifically a part of the syntax. Since you can just put
parens around the whole expression (to help with wrapping etc), I
don't see a compelling reason to put them around just the except bit.

> Since they ought to be
> separated by commas, and stylistically they ought to be split
> one-per-line, I prefer the bracket-less version when there is only a
> single except:
>
>     thing(a, b) except ThisError, ThatError: default
>
> and brackets when there are more than one:
>
>     thing(a, b) (except ThisError, ThatError: default,
>                  except SpamError, EggsError: something,
>                  except OutOfCheeseError: different_thing,
>                  )

Move the open parenthesis to before thing(a, b) and you have what I
would be recommending.

I'm +0 on the explicit comma separation between except clauses. Will
add that to the proposal, complete with a caution about it being a
potential bug magnet.

> I can't think of any places where parens are explicitly prohibited. They
> used to be prohibited in imports, but that's no longer the case. One
> should always be allowed to use parens for grouping and implicit line
> continuations, nearly everywhere.

They're prohibited in the middles of things. You can't, for instance,
put parens around a few of a function's arguments (if they're pure
positional then it's legal but has other meaning, and other notations
are syntax errors). The inside of ( ) generally has to be a valid,
parseable expression.

> How does this suggested syntax look with Raymond's recent example?
> Raymond regretted that max and min now take a "default" argument, as of
> Python 3.4. Let's compare:
>
>     result = max(some_numbers, key=foo, default=float('nan'))
>
>     result = max(some_numbers, key=foo) except ValueError: float('nan')
>
> Looks damn good to me!

Yeah. I especially like how this means the author of max() doesn't
need to think about this possibility. (I'm still trying to come up
with, in my head, an external means of chaining method calls - one
that makes sense and looks clean. Same reason; the method author
shouldn't have to think in terms of chaining.)

>> >Incidentally, I'm looking at this being able to chain quite nicely:
>> >
>> >((expr except Exception1: default1) except Exception2: default2)
>
> This is equivalent to:
>
>
> try:
>     try:
>         result = expr
>     except Exception1:
>         result = default1
> except Exception2:
>     result = default2

Yes, as MRAB pointed out. I've updated the PEP to note this. The
syntactic form has to itself understand chaining.

>> >I've mailed the first-draft PEP to peps@; is it appropriate to post it
>> >here as well, or should I wait to hear back from peps@?
>
> I think it is perfectly appropriate to post a draft PEP here.

Okay. Will post that separately to this.

ChrisA


More information about the Python-ideas mailing list