<div dir="ltr">[This is my one reply in this thread today. I am trying to limit the amount of time I spend to avoid another overheated escalation.]<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 25, 2018 at 4:44 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right, the proposed blunt solution to "Should I use 'NAME = EXPR' or<br>
'NAME := EXPR'?" bothers me a bit, but it's the implementation<br>
implications of parent local scoping that I fear will create a<br>
semantic tar pit we can't get out of later.<br></blockquote><div><br></div><div>Others have remarked this too, but it really bother me that you are focusing so much on the implementation of parent local scoping rather than on the "intuitive" behavior which is super easy to explain -- especially to someone who isn't all that familiar (or interested) with the implicit scope created for the loop control variable(s). According to Steven (who noticed that this is barely mentioned in most tutorials about comprehensions) that is most people, however very few of them read python-dev.<br></div><div><br></div><div>It's not that much work for the compiler, since it just needs to do a little bit of (new) static analysis and then it can generate the bytecode to manipulate closure(s). The runtime proper doesn't need any new implementation effort. The fact that sometimes a closure must be introduced where no explicit initialization exists is irrelevant to the runtime -- this only affects the static analysis, at runtime it's no different than if the explicit initialization was inside `if 0`.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Unfortunately, I think the key rationale for (b) is that if you<br>
*don't* do something along those lines, then there's a different<br>
strange scoping discrepancy that arises between the non-comprehension<br>
forms of container displays and the comprehension forms:<br>
<br>
    (NAME := EXPR,) # Binds a local<br>
    tuple(NAME := EXPR for __ in range(1)) # Doesn't bind a local<br>
[...]<br>
Those scoping inconsistencies aren't *new*, but provoking them<br>
currently involves either class scopes, or messing about with<br>
locals().<br></blockquote><div><br></div><div>In what sense are they not new? This syntax doesn't exist yet.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The one virtue that choosing this particular set of discrepancies has<br>
is that the explanation for why they happen is the same as the<br>
explanation for how the iteration variable gets hidden from the<br>
containing scope: because "(EXPR for ....)" et al create an implicitly<br>
nested scope, and that nested scope behaves the same way as an<br>
explicitly nested scope as far as name binding and name resolution is<br>
concerned.<br></blockquote><div><br></div><div>Yeah, but most people don't think much about that explanation.</div><div><br></div><div>You left out another discrepancy, which is more likely to hit people in the face: according to your doctrine, := used in the "outermost iterable" would create a local in the containing scope, since that's where the outermost iterable is evaluated. So in this example<br></div><div><br></div><div>    a = [x := i+1 for i in range(y := 2)]</div><div><br></div><div>the scope of x would be the implicit function (i.e. it wouldn't leak) while the scope of y would be the same as that of a. (And there's an even more cryptic example, where the same name is assigned in both places.)<br></div><div><br></div><div>This is another detail of comprehensions that I assume tutorials (rightly, IMO) gloss over because it's so rarely relevant. But it would make the explanation of how := works in comprehensions more cumbersome: you'd have to draw attention to the outermost iterable, otherwise "inline assignment in comprehensions has the same scope as the comprehension's loop control variable(s)" would lead one to believe that y's scope above would also be that of the implicit function.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Parent local scoping tries to mitigate the surface inconsistency by<br>
changing how write semantics are defined for implicitly nested scopes,<br>
but that comes at the cost of making those semantics inconsistent with<br>
explicitly nested scopes and with the read semantics of implicitly<br>
nested scopes.<br></blockquote><div><br></div><div>Nobody  thinks about write semantics though -- it's simply not the right abstraction to use here, you've introduced it because that's how *you* think about this.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The early iterations of PEP 572 tried to duck this whole realm of<br>
potential semantic inconsistencies by introducing sublocal scoping<br>
instead, such that the scoping for assignment expression targets would<br>
be unusual, but they'd be consistently unusual regardless of where<br>
they appeared, and their quirks would clearly be the result of how<br>
assignment expressions were defined, rather than only showing up in<br>
how they interacted with other scoping design decisions made years<br>
ago.<br></blockquote><div><br></div><div>There was also another variant in some iteration or PEP 572, after sublocal scopes were already eliminated -- a change to comprehensions that would evaluate the innermost iterable in the implicit function. This would make the explanation of inline assignment in comprehensions consistent again (they were always local to the comprehension in that iteration of the PEP), at the cost of a backward incompatibility that was ultimately withdrawn.</div></div><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div></div>