[Python-ideas] If branch merging

[Nick Coghlan]

On 8 June 2015 at 22:12, Steven D'Aprano <steve at pearwood.info> wrote:

[In relation to named subexpressions leaking to the surrounding
namespace by default]
> I agree with that in regard to the function call. It just feels wrong
> and icky for a binding to occur inside a function call like that. But
> I don't think I agree with respect to the rest. To answer Andrew's later
> question:
>
>> What does "x[(a.b as b)] = b" mean
>
> surely it simply means the same as:
>
>     b = a.b
>     x[b] = b

Right, but it reveals the execution order jumping around in a way that
is less obvious in the absence of side effects. That is, for side
effect free functions, the order of evaluation in:

    x[a()] = b()

doesn't matter. Once side effects are in play, the order matters a lot more.

> Now we could apply the same logic to a function call:
>
>     # func(a.b as b)
>     b = a.b
>     func(b)
>
> but I think the reason this feels wrong for function calls is that it
> looks like the "as b" binding should be inside the function's scope
> rather than in the caller's scope. (At least that's what it looks like
> to me.) But that doesn't apply to the others. (At least for me.)
>
> But frankly, I think I would prefer to have b escape from the function
> call than to have to deal with a bunch of obscure, complicated and
> unintuitive "as" scoping rules. Simplicity and predictability counts for
> a lot.

Hence the ongoing absence of named subexpressions as a feature - the
simple cases look potentially interesting, but without careful
consideration, the complex cases would inevitably end up depending on
CPython specific quirks in subexpression execution order.

Cheers,
Nick.

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