[Python-ideas] except expression

[Georg Brandl]

Am 13.02.2014 13:50, schrieb Nick Coghlan:
> On 13 February 2014 20:10, M.-A. Lemburg <mal at egenix.com> wrote:
>> On 13.02.2014 10:24, Nick Coghlan wrote:
>>> General comment: like Raymond, I'm inclined to favour a nice expression
>>> friendly exception handling syntax, precisely because of the proliferation
>>> of relatively ad hoc alternative solutions (in particular, the popularity
>>> of being able to pass in default values to handle empty iterables).
>>
>> Here's a variant the resembles the code you'd write in a helper
>> function to achieve the same thing, only stripped down somewhat:
>>
>> x = something() except ValueError return default_value
>>
>> def try_something():
>>     try:
>>         return something()
>>     except ValueError:
>>         return default_value
>>
>> x = something() except ValueError as exc return exc.message
>>
>> def try_something():
>>     try:
>>         return something()
>>     except ValueError as exc
>>         return exc.message
>>
>> Obviously, having a keyword "use" would make a better fit :-)
>>
>> x = something() except ValueError use default_value
> 
> Even if we don't agree on a resolution for 3.5, I think there's more
> than enough interest for it to be worth someone's while to collate
> some of the proposals in a PEP - if nothing else, it will save
> rehashing the whole discussion next time it comes up :)
> 
> The benefits of this:
> 
> - the status quo is that various APIs are growing "default" parameters
> to handle the case where they would otherwise throw an exception
> - this is creating inconsistencies, as some such functions can be used
> easily as expressions without risking any exception (those where such
> a parameter has been added), as well as a temptation to use "Look
> Before You Leap" pre-checks, even in cases where exception handling
> would be a better choice
> - sequence indexing is a case where there is no current standard
> mechanism for providing a default value, so you're either use a
> pre-check for the system length, or else using a full try statement or
> context manager to handle the IndexError
> - by providing a clean, expression level syntax for handling a single
> except clause and providing an alternate value for the expression,
> this problem could be solved once and for all in a systematic way,
> rather than needing to incrementally change the API of a variety of
> functions (as well as addressing the container subscripting case in a
> way that doesn't require switching away from using the subscript
> syntax to a normal function call, or switching from use an expression
> to a statement)
> 
> 
> Some of the specific syntactic proposals:
> 
>     x = op() except default if Exception
>     x = op() except default for Exception
>     x = op() except default from Exception
>     x = op() except Exception return default
> 
>     x = op() except exc.attr if Exception as exc
>     x = op() except exc.attr for Exception as exc
>     x = op() except exc.attr from Exception as exc
>     x = op() except Exception as exc return exc.attr

For me any proposal that doesn't pair "except" with the exception class(es)
like the statement version does would be right out.

It will be hard enough to remember the order of the expression, but "in
the try-except block except gets the exception class, in the except
expression it gets the default value and the exception class is specified
with FOO" is silly.

Georg