[Python-ideas] except expression

[Chris Angelico]

On Mon, Feb 17, 2014 at 5:24 PM, Rob Cliffe <rob.cliffe at btinternet.com> wrote:
> So in
>         1 / x except ZeroDivisionError: 42
> an error will be trapped evaluating "1/x" (not just "x") because "/" has
> higher precedence than "except", as we would all expect.

Yes, definitely. Operator precedence can (and should) be used to make
this do exactly what everyone expects. Though there's a proposal on
the board to demand parens:

(1 / x except ZeroDivisionError: 42)

which would settle the deal.

> I don't see (though I could be missing something) that "finally" makes any
> sense inside an expression.  "finally" introduces an action to be performed
> regardless of whether a preceding operation raised an error.  Here we are
> evaluating an expression, and to tack on "I want to perform this action" on
> the end of an expression seems weird (and better done by the existing try
> ... finally mechanism).  It did occur to me briefly that it might be used to
> provide a final default:
>     x = eval(UserExpression) except NameError: "You forgot to define
> something" except ZeroDivisionError: "Division by zero" finally: "Some error
> or other"
> but this would be pretty well equivalent to using a bare "except:" clause,
> or "except BaseException".

Agreed, finally makes no use. That section has been reworded, but is
worth keeping.

> Oh yes, by the way, I think that a bare "except:" should be legal (for
> consistency), albeit discouraged.

Agreed. Never even thought about it, but yes, that's legal. No reason
to forbid it. Added a sentence to the PEP to say so.

> I would argue against comma separators being allowed:
>     1) They add extra grit to the syntax.
>     2) When the parser sees a comma, it doesn't know if this is terminating
> the except clause, or part of a tuple default value:
>         value = expr except Exception1: x,y, except Exception2: z
>         (The ambiguity is resolved when it sees another "except".  The
> intervening comma just adds confusion and makes the parser's job harder.)
>        And for what it's worth, if you did want a 1-element tuple as your
> default value you might write the ugly
>        value = expr except Exception1: x,, except Exception2: z   # Yuk!
> Please put "x," inside parentheses.
>     3) With "no commas", the subtly different semantics you mention would be
> distinguished transparently by
>
>         value = expr except Exception1: default1 except Exception2: default2
>         value = (expr except Exception1: default1) except Exception2:
> default2
> In the first form, Exception2 will not be caught if it is raised evaluating
> default1.  In the second it will be.

I'm not convinced either way about the commas, at the moment. At some
point, I'm probably going to have to come up with a bunch of actual
examples (real-world or synthesized) and then show how each would be
written as a statement, and then as an expression, and show the latter
with the full cross-multiplication of proposals: commas or not, parens
or not, etc, etc, etc.

In any case, I'm pretty happy with the level of interest this is
generating. A number of people have strong opinions on the matter.
That's a good sign!

I'm happy to re-post the current version of the PEP any time people
like; or, if it makes sense, I could shove the repository onto github
so people can see the changes live. At some point, of course, the
authoritative text will be in the official PEP repository, but until
then, I'm open to suggestions.

ChrisA