[Python-ideas] except expression

[Yann Kaiser]

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:

    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/