[Python-Dev] Alternative forms [was: PEP 463: Exception-catching expressions]

[Jim J. Jewett]

The PEP currently says:

> Alternative Proposals
> =====================

> Discussion on python-ideas brought up the following syntax suggestions::

>    value = expr except default if Exception [as e]

This one was rejected because of the out-of-order evaluation.

Note, however, that the (farthest left) expr is always evaluated first;
the only out-of-order evaluation is "default if Exception".

"default if Exception" is precisely the same evaluation order
(clause after the "if" skips ahead of the clause before the "if")
as in the existing if-expression, and the existing if-filters in
comprehensions.

The same justifications for that order violation generally apply here too.
You can argue that they weren't sufficient justification in the first
place, but that is water under the bridge; *re*-using out-of-order-"if"
shouldn't add any additional costs.

[Err... unless people take the "if" too literally, and treat the
Exception clause as a boolean value, instead of as an argument to the
"except" keyword.]

The advantages of this form get much stronger with [as e] or multiple
different except clauses, but some of them do apply to even the simplest
form.  Notably, the "say it like you would in English" that convinced
Perl still applies: "if" *without* a "then" is normally an extra condition
added after the main point:

    Normally ham, but fish if it's a Friday.

(Admittedly, the word "then" *can* be elided (and represented by a slight
pause), and python programmers are already used to seeing it represented
only by ":\n")


I also give a fair amount of weight to the fact that this form starts to
look awkward at pretty much the same time the logic gets too complicated
for an expression -- that should discourage abuse.

[The analogies to if-expressions and if-filters and to spoken English,
along with discouragement for abuse, make this my preferred form.]



...
>    value = expr except (Exception [as e]: default)

(and the similar but unmentioned)

    value = expr except (Exception [as e] -> default)

The mapping analogy for ":" is good -- and is the reason to place
parentheses there, as opposed to around the whole expression.  Your
preferred form -- without the internal parentheses -- looks very
much like a suite-introduction, and not at all like the uses
where an inline colon is acceptable.

I do understand your concern that the parentheses make "except (...)"
look too much like a function call -- but I'm not sure that is all bad,
let alone as bad as looking like a suite introduction.

Both ":" and "->" are defined for signatures; the signature meaning
of ":" is tolerable, and the signature meaning of "->" is good.



...
>    value = expr except Exception [as e] continue with default

This one works for me, but only because I read "continue with" as a
compound keyword.  I assume the parser would too.  :D  But I do
recognize that it is a poor choice for those who see the space as a
more solid barrier.


...
>    value = expr except(Exception) default # Catches only the named type(s)

This looks too much like the pre-"as" way of capturing an exception.



>    value = default if expr raise Exception

(Without new keyword "raises",) I would have to work really hard not to
read that as:

    __temp = default
    if expr:
        raise Exception
    value = __temp



>    value = expr or else default if Exception

To me, this just seems like a wordier and more awkward version of

    expr except (default if Exception [as e])

including the implicit parentheses around "default if Exception".


>    value = expr except Exception [as e] -> default

Without parens to group Exception and default, this looks too much like
an annotation describing what the expr should return.


    value = expr except Exception [as e] pass default

I would assume that this skipped the statement, like an if-filter
in a comprehension.



> All forms involving the 'as' capturing clause have been deferred from
> this proposal in the interests of simplicity, but are preserved in the
> table above as an accurate record of suggestions.

Nick is right that you should specify whether it is deferred or
rejected, because the simplest implementation may lock you into
too broad a scope if it is added later.



> The four forms most supported by this proposal are, in order::

>    value = (expr except Exception: default)
>    value = (expr except Exception -> default)

...

If there are not parentheses after "except", it will be very tempting
(and arguably correct) to (at least mentally) insert them around the
first two clauses -- which are evaluated first.  But that leaks into

    value = (expr except Exception): default

which strongly resembles the suite-starter ":", but has very little
in common with the mapping ":" or the signature ":".

    value = (expr except Exception) -> default

which looks like an annotation, rather than a part of the value-determination.



-jJ

--

If there are still threading problems with my replies, please
email me with details, so that I can try to resolve them.  -jJ