[Python-ideas] except expression

[Chris Angelico]

On Wed, Feb 19, 2014 at 1:07 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 18 February 2014 13:37, Chris Angelico <rosuav at gmail.com> wrote:
>> On Wed, Feb 19, 2014 at 12:00 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>>> On 18 February 2014 12:49, MRAB <python at mrabarnett.plus.com> wrote:
>>>>> I really think that this proposal needs to focus on the short, simple
>>>>> use cases and *not* worry about too much generality. For example:
>>>>>
>>>>>     sum(x[3] except 0 for x in list_of_tuples)
>>>>>
>>>> Shouldn't that be:
>>>>
>>>>
>>>>     sum(x[3] except: 0 for x in list_of_tuples)
>>>>
>>>> (colon added)?
>>>
>>> Only if you feel that a colon is necessary for the syntax. I don't :-)
>>
>> The colon is necessary if the new syntax should allow the
>> specification of the exception. If it's always equivalent to a bare
>> except that doesn't capture the exception object, then it'd be
>> unnecessary.
>
> Well, yes and no. There are only 2 out of the 10 syntaxes originally
> proposed in the PEP at the start of this thread that use a colon. I've
> already pointed out that I don't like a colon, so assume I said
> "except return 0" if you must :-)

Whether it's a colon or another keyword, _something_ is necessary in
there, if it's permissible to specify an exception type:

sum(x[3] except IndexError 0 for x in list_of_tuples)
sum(x[3] except 0 for x in list_of_tuples)

How would you parse each of those, without a separator?

One option might be to have a separator that's present only when the
exception type is listed. For instance:

sum(x[3] except(IndexError) 0 for x in list_of_tuples)
sum(x[3] except 0 for x in list_of_tuples)

Does that sort of thing have enough support to be added to the PEP?
I'm not sure it gives us anything over the colon notation, which has
the benefit of being consistent with the statement form (and is
stylistically similar to lambda, so it's not grossly inappropriate to
an expression context). The separator can only be omitted if there's
exactly two parts to this new syntax, the "try-me" expression and the
"give this instead if any exception is thrown" one. And that's the
form that I'm strongly disliking, as I said in the next bit.

>> Personally, I don't want to create a special syntax that does
>> something that's strongly discouraged. I'm open to argument that the
>> expression-except should accept just a single except clause; I'm open
>> to argument that it shouldn't be able to capture (due to complications
>> of creating sub-scopes), though that's more a nod to
>> implementation/specification difficulty than any conceptual dislike of
>> the syntax (it's clean, it's consistent, it's sometimes useful); but I
>> don't want to narrow this down to always having to catch everything.
>
> That's a fair point, certainly, and probably worth capturing
> explicitly in the PEP if it's not already there. I could argue that
> "bare except" is more acceptable in an *expression* context because
> expressions should never be so complex that the reasons why it's bad
> in a statement context actually apply. But I'd only be playing devil's
> advocate by doing so. My main point here was to force attention back
> onto the *real* use cases which (as I see it) are very simple
> exception handling for a simple subexpression embedded in a compound
> expression. Examples of how you could catch 3 different exceptions,
> use exception data, etc, are to my mind missing the point. At that
> stage, factor out the expression and use try/except *statements* and a
> temporary variable.

Fair point. This should be kept simple. So, let's see. I don't feel
like crafting a regular expression that searches the standard library
for any one-line try block that assigns to something, so I guess I
should figure out how to use ast features other than literal_eval...
and it's not making it easy on me. But we'll get there.

ChrisA