[Python-ideas] except expression

[Nick Coghlan]

On 19 February 2014 23:52, Chris Angelico <rosuav at gmail.com> wrote:
> On Thu, Feb 20, 2014 at 12:39 AM, Steven D'Aprano <steve at pearwood.info> wrote:
>> On Wed, Feb 19, 2014 at 10:28:59PM +1000, Nick Coghlan wrote:
>>
>>> Either way, based on your survey of the stdlib, I agree with MAL's
>>> suggestion to also rule out embedded name binding. The example you
>>> give in the PEP of losing the distinction between whether an iterator
>>> yielded a new incremental value or terminated and returned a final
>>> value is another sign that allowing name binding is a potential bug
>>> magnet, because it conflates two different return channels into one.
>>
>> Hmmm, I think that's a bit strong. If combining the iterator's yield
>> value and the iterator's return value is a mistake, that's not the
>> syntax that makes it a mistake, it's that the very idea of doing so is
>> wrong.
>
> And by the way, I'd say that it's wrong *in the general sense* to
> conflate yield/return, but such conflations happen all the time. We
> can use 'or' to turn any falsy value into some specific thing:
>
> def foo(widget, n=None):
>     """Frob the widget n times, or once for each spam"""
>     for i in range(n or len(widget.spam)):
>         widget.frob()
>
> Nobody would ever suggest that 0, None, [], and "" should all be
> treated the same everywhere, but pass any of them to this function and
> it'll do the same thing.
>
> By moving the conflation as far outward as possible, we maintain the
> distinction as long as possible. At the point where the programmer
> knows that the two channels must mean the same thing, they can get
> merged. It's like merging stdout and stderr of a process prior to
> giving the text to a human.

Right, but people can still use the statement form or a context
manager to help handle that. We don't need to introduce a quaternary
expression with complex scoping issues for it.

Since dropping the optional "as" clause drastically simplifies the
proposal (no need for a hidden scope), and the use case for it isn't
at all compelling, that puts it in the "don't bother" category for me.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia