<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 27, 2018 at 6:56 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">[...] </span>The implicit functions used in the<br>
comprehension & generator expression cases are just potentially<br>
simpler to handle, as we don't care about their API signatures, which<br>
means we can freely pollute their APIs with eager name bindings if we<br>
choose to do so. [...]<br></blockquote></div><br></div><div class="gmail_extra">Hm, so maybe we shouldn't touch lambda, but we can at least fix the scope issues for comprehensions and genexprs.<br><br>There may still be breakage, when the code defines a global x that is overridden by a class-level x, and a class-level comprehension references x assuming it to be the global. So we need to tread carefully even here -- but this case is weird already:<br><br></div><div class="gmail_extra">x = 42<br></div><div class="gmail_extra">class C:<br></div><div class="gmail_extra">    x = [1, 2, 3]<br></div><div class="gmail_extra">    z = [x+y for y in x]  # [43, 44, 45]<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>