[Python-ideas] except expression

[Rob Cliffe]

On 19/02/2014 00:43, Steven D'Aprano wrote:
> On Tue, Feb 18, 2014 at 03:56:10PM +0000, Paul Moore wrote:
>> On 18 February 2014 15:05, Chris Angelico <rosuav at gmail.com> wrote:
>>>> 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?
>> With "return" as a separator. I said that above. Was I not clear?
> Yes you were clear, but this is a huge complicated thread and if Chris
> is the least bit like me, he's probably feeling a bit overloaded :-)
>
> Using return to not actually return seems completely wrong to me. This
> is the problem with all the proposals to overload some arbitrary keyword
> *just because it is available*. To me, all of these are equally as
> arbitrary and silly:
>
>      expression except return 42
>      expression except pass 42
>      expression except del 42
>      expression except import 42
>      expression except class 42
I agree.  For me, "return" would be the least indigestible - at least it 
suggests getting a value and parking it somewhere.  My support for the 
colon is based on (1) its conciseness (2) its natural meaning in my 
mind, something like "here follows" (3) a somewhat fanatical hankering 
for consistency - there is a colon at the end of an "except" statement.  
(Although actually I would prefer that "if", "while", "try", "except" 
etc. statements _didn't_ require a colon - I still forget to put them in 
sometimes.  Not sure where that leaves me.)
>
> For each keyword in (return, pass, del, import, ...), we are attempting
> to overload it to mean something different inside an except expression
> to what it does outside of one.
>
> With return and pass, if we squint and turn our heads to the side, we
> might be able to persuade ourselves that there is a vague analogy
> between what the keyword does outside of expression to what it does
> inside ("it returns from the expression, but not from the function" sort
> of thing). But I don't consider vague analogies to be a good enough
> reason to overload a keyword with two distinct uses.
>
> Is anyone going to propose some other, new, keyword? Although the
> barrier to new keywords is high, it's not impossibly high. It's worth at
> least considering.
I confess I don't understand what the issues are that makes the barrier 
so high, and I willingly defer to those who know more about it than I 
do.  But if we admit the possibility, "then" is the best candidate I can 
think of:

     x = d[y] except KeyError then z
>
>
>> I remain less than happy with the colon notation, although I will
>> concede that the basic
>>
>>      x[3] except IndexError: 0
>>
>> form is not horrible - it just becomes horrible very, very fast when
>> people try to do anything more complicated than that.
> Really? I think adding a second exception to the same clause is not
> horrible at all.
>
>      x[3] except IndexError, KeyError: 0
>
> Parens around the exception list should be permitted, but I don't think
> they need to be mandatory:
>
>      x[3] except (IndexError, KeyError): 0
You strike a chord with me, if only because I spend half my time with a 
language that requires parentheses round everything, ergo I'm biased.
But more seriously, Python generally does not require parentheses unless 
there's a very good reason.
>
> If we allow multiple except clauses -- and I am +1 on that -- then it
> should be recommended to put one except clause per line, indented for
> clarity where needed:
>
>
> my_values = [# existing syntax
>               lambda a, b: (a+b)/(a*b),
>               somelist[2:-1],
>               {key: value for key in sequence},
>               some_function(x) if x else -1,
>               # proposed new syntax
>               (minmax(sequence) except ValueError: (-1, -1)),
>               (str(x[3]) except IndexError, KeyError: 0,
>                          except NameError: UNDEF,
>                          except UnicodeDecodeError: '?',
>                          ),
>               ]
>
>
> As you can see from my examples, using colons is hardly unheard of, and
> while multiple except clauses does make the except expression more
> complicated, the use of parens and sensible formatting allows you to
> digest it a bit at a time.
>
> Of course people might abuse this. But they might abuse list comps,
> generator expressions, ternary if, and even mathematical expressions
> too. In practice we solve that by slapping them with a halibut :-) and
> saying "don't do that".
>
>
>
I pretty much agree with everything you have said in this post. (Kinda 
nice, as we had a violent disagreement in the past. :-) )

Rob Cliffe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140219/4f634aa6/attachment.html>