[Python-ideas] except expression

[M.-A. Lemburg]

On 20.02.2014 15:49, Andrew Barnert wrote:
> On Feb 20, 2014, at 5:45, "M.-A. Lemburg" <mal at egenix.com> 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.
>>
>> The colon should stay reserved for starting new blocks of statements.
> 
> So you don't like the colon in lambdas, dict displays, or slices?

Ok, that sentence was oversimplified :-)

The proposed syntax looks too much like the regular try-except syntax
which uses the colon to signal the start of a new block of statements.

> [snip]
> 
>> 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.
> 
> Agreed. Especially after Nick Coghlan demonstrated that we already have a more readable and more concise way to do it without abusing anything:
> 
>     with suppress(IOError): os.remove('/')
> 
> Who sees that and says, "I like that it's one line, but if only it could be a longer line, with more keywords, and misleadingly imply a useful value"?
> 
> [snip]
> 
>> 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.
> 
> There's no "sort of" about it; you want lambda with a nicer syntax.

.. and without the function call overhead :-)

> I sympathize with that. Why do you think Haskell gets away with catch being a function when other functional languages don't? Maybe it's this:
> 
>     catch \-> expensive_call \-e> (dangerous_default e)
> 
> vs. this:
> 
>     catch(function() { expensive_call() }, function(e) { dangerous_default(e) }
> 
> That being said, I don't know that it would have the same benefits in Python. In a language that already encourages defining functions all over the place like JavaScript or OCaml, the verbose syntax is painful. But Python isn't like that. Haskell also has a one-character compose operator, which I love in Haskell and would love in JS, but I don't miss it in Python. (We don't even have a compose function in the stdlib.) Python lets you use functional style when it's the obvious way to express something, but doesn't force it on you when it isn't.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 20 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2014-02-12: Released mxODBC.Connect 2.0.4 ...     http://egenix.com/go53

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/