<p dir="ltr"><br>
On 10 Jun 2015 05:00, "Wolfram Hinderer" <<a href="mailto:wolfram.hinderer@googlemail.com">wolfram.hinderer@googlemail.com</a>> wrote:</p>
<p dir="ltr">>><br>
>><br>
> Hm, that's my point, isn't it?<br>
> The evaluation of subscript() happens after the evaluation of value().<br>
> The object that the RHS evaluates to (i.e. value()) is determined before subscript() is evaluated. Sideeffects of subscript() may mutate this object, but can't change *which* object is assigned.<br>
> But if<br>
><br>
><br>
>     x[(a.b as b)] = b<br>
><br>
> means<br>
><br>
>     b = a.b<br>
>     x[b] = b</p>
<p dir="ltr">That would be:</p>
<p dir="ltr">    x[b] = (a.b as b)</p>
<p dir="ltr">> then the evaluation of the LHS *does* change which object is assigned. That's why I asked for clarification.</p>
<p dir="ltr">Execution order wouldn't change, so it would mean the following:</p>
<p dir="ltr">    _temp = b<br>
    b = a.b<br>
    x[b] = _temp</p>
<p dir="ltr">This means you'd get the potentially surprising behaviour where the name binding would still happen even if the subscript assignment fails.</p>
<p dir="ltr">However if name bindings *didn't* leak out of their containing expression by default, and while/if/elif code generation instead gained machinery to retrieve the name bindings for any named subexpressions in the condition, that would eliminate most of the potentially bizarre edge cases.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>