[Python-ideas] except expression

[Chris Angelico]

On Thu, Feb 20, 2014 at 11:22 AM, Yury Selivanov
<yselivanov.ml at gmail.com> wrote:
> If we add new 'raises' keyword, then we can have the following
> new syntax:

Cost of adding a keyword is based on its usage. Searching the standard
library for 'raises' comes up blank; same goes for 'then', though both
'use' and 'when' do come up (once and twelve times, respectively). I
think it reasonably unlikely that 'raises' will be a problem. However,
it's very similar to an existing keyword. The English form sounds a
little archaic, but plausible: "Do this if spam raise something".

> # set 'value' to 42 if len(a) < 10
> # or else, return a[10]
> value = 42 if a[10] raises IndexError

(Minor point: That should be 42 if len(a) <= 10.)

> # set 'value' to 42 if len(a) < 10
> # or else, return 'spam'
> value = 42 if a[10] raises IndexError else 'spam'

Have you a use-case for this? It completely ignores the original
expression value.

> # same as above but if a[10] raises anything
> value = 42 if a[10] raises

I'm giving this an immediate common-law rejection, as the bare-except
sub-proposal has already been rejected.

> # another example
> foo(None if dct['key'] raises)

And what if it doesn't? Reads nicely for the exceptional case.
Presumably it's the value of dct['key'] if it doesn't raise, but
that's not obvious from how it reads.

> This syntax doesn't provide:
> - finally statement replacement;
> - handling multiple exceptions;
> - rerising exception;
> which I think is a good thing. No need to complicate this
> syntax.

I'm fine with those absences.

> Pros:
> - easy to read (like English or pseudocode)
> - looks like existing 'expr if expr else expr' syntax
>
> Cons:
> - adds a new keyword

That's not a killer, by any means.

My main objection here is that it reads backwards. This is an issue
with the "if/else" operator in Python, too. The actual evaluation
order has to be:

1) Base expression
2) Exception list
3) Default expression

I could accept switching 1 and 2, since the exception list will
normally be constant anyway (some of the functional forms effectively
do this, by having lambdas for the other two but not for the
exception_list), but quite a few good use-cases depend on the default
expression being calculated lazily.

So if the base expression is evaluated before the default expression,
it makes better sense to put base to the left of default. That way,
the expression reads in the order that it should:

>>> [print("1"), print("2")][print("3") or 0]
1
2
3

>>> print("2") if not print("1") else print("n/a")
1
2

There's no changing if/else, but I'm still inclined to support
proposals that put the expressions in the "correct order". That's not
a clincher on its own, but I want to see a compelling use-case that
justifies the out-of-order layout.

ChrisA