[Python-ideas] except expression

[Andrew Barnert]

On Feb 20, 2014, at 7:24, Yann Kaiser <kaiser.yann at gmail.com> wrote:

> I too am uncomfortable with re-purposing except ...: from introducing
> a block to introducing either a block or an expression. "Keyword then
> colon" is a great indicator for when you should start a new indent,
> especially with regards to learners. Lambda undermines this enough as
> it is, and dicts/slices don't have a keyword preceding them.
> 
> I think we aren't going deep enough into the rabbit hole. Why restrain
> ourselves to trying to cram try-except-finally into an expression,
> losing the finally part, when we already have a tool right under our
> eyes, as Nick Coghlan pointed out, which leverages try-except-finally
> entirely in a concise fashion, the with statement.
> 
> If context managers are amended to support a return value(maybe even
> transforming one?), a with-expression could look like:

This is a really interesting idea. Or maybe two connected but somewhat separate ones. Either way, I think this is worth fleshing out and making a new post out of. I suspect a lot of people will miss it buried in the middle of this gigantic thread.

>    last = L.pop() with default(None, IndexError)
>    x = expr with produce_default(expensive_op, AnException)
>    contents = f.read() with open('filename') as f
>    d = Decimal(1) / Decimal(7) with Context(prec=5)
> 
> The syntax is cleaner, including when easing the original problem, and
> is capable of so much more. I seem to be lacking modesty today,
> because it seems like this is worth scrapping except-expression for
> it.
> 
> (Sorry for the incorrect placement of my reply, I just subscribed.)
> 
> On 20 February 2014 15:49, Andrew Barnert <abarnert at yahoo.com> 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?
>> 
>> [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.
>> 
>> 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.
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/