[Python-ideas] except expression

[Rob Cliffe]

On 20/02/2014 13:45, M.-A. Lemburg wrote:
> On 20.02.2014 02:18, Chris Angelico wrote:
>> On Thu, Feb 20, 2014 at 11:15 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
>>> result = 1/x except ZeroDivisionError -> NaN
>>>
>>> For the record, I could just as easily live with the colon instead of the
>>> arrow.
>>>
>> Time to open up this branch of the discussion... colon or arrow?
>>
>> For the purposes of this debate, I'm comparing these two notations,
>> and nothing else:
>>
>> result = 1/x except ZeroDivisionError -> NaN
>> result = 1/x except ZeroDivisionError: NaN
> I'm -1 on both of them.
I'm afraid answering your post will mean repeating stuff said earlier in 
this thread, but here goes:
> The colon should stay reserved for starting new blocks of statements.
It isn't reserved for that - it is already used for slices, dictionary 
literals and lambdas.
> The arrow is used for return type annotations, which is a completely
> different concept than returning values.
(I'm not so keen on the arrow myself but) with a limited set of 
characters, some of them have to perform more than one role, as colons, 
dots, parentheses and braces (to name but a few) already do.
>
> I also find it disturbing that people are actually considering
> to use this expression form as a way to do quick&dirty suppression
> of exceptions.
This is a relatively common construction (as a survey of my own small 
codebase indicates).  Quick, yes.  How dirty it is depends entirely on 
context, (and how readable it can be made) and is up to the programmer's 
judgment.
>
> The intended use case should really be limited to providing default
> values for functions or methods that are expected to return a value.
That's your opinion.  Why, if it is useful in other ways?    [1]
>
> Abusing the fact that procedures in Python return None (simply
> because we don't have procedures and need to use functions instead)
> to make use of except expressions would make code less readable.
I don't quite see the relevance.  None of your examples rely on a 
function returning None.  Could you give an example?
>
> x = data[1] except IndexError return None # is readable
Agreed.
> f = open('x.txt', 'r') except IOError return None # is probably not a good idea
I personally think this could be spelt more readably (with a colon or 
"then").  But however it's done, it's a meaningful and useful construct.
> os.remove('/') except IOError return None # is really bad style
Do you mean because it's not very readable (I agree) or because it's 
necessarily a bad thing to do (I disagree, particularly if we chose a 
less drastic example)?
>
> The purpose of such except expressions should be to work around
> small corner cases, not to address important exceptional cases
> in ones applications.
See [1] above.
>
>
> Sometimes I wish we had expression objects in Python to wrap
> expressions without evaluating them - sort of like lambdas
> without arguments but with a nicer syntax. These could then
> be used to implement a default() builtin.
>
> Here's a version using lambdas as example:
>
> def default(expr, value=None, *exceptions):
>      try:
>          expr()
>      except exceptions:
>          return value
>
> x = default(lambda: 1/0, None, ZeroDivisionError)
>
> print (x)
>
This is interesting.  Expression objects might be useful in various 
ways.  But it seems a rather circuitous and obscure way to provide a 
default value after an exception, and harder to extend:
x = default(lambda: d1[key], default(lambda:d2[key], None, KeyError), 
KeyError) # And I hope I've spelt it right!

Rob Cliffe