<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 3 March 2018 at 03:51, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03/02/2018 02:47 AM, Nick Coghlan wrote:<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2 March 2018 at 16:39, Ethan Furman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/01/2018 09:08 PM, Nick Coghlan wrote:<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Adding statement local variables into that mix *without* some form of syntactic marker would mean taking an already<br>
complicated system, and making it even harder to reason about correctly (especially if statement locals interact<br>
with nested scopes differently from the way other locals in the same scope do).<br>
</blockquote>
<br>
Seems like it would far easier and (IMHO) more useful to scale the proposal back from a statement scope to simple<br>
expression assignment, and the variable is whatever scope it would have been if assigned to outside the expression<br>
(default being local, but non-local or global if already declared as such).<br>
</blockquote>
<br>
Because that would put us back in the exact same problematic situation we had when "[x*x for x in sequence]" leaked the<br>
iteration variable (only worse): no function locals would be safe, since arbitrary expressions could clobber them, not<br>
just name binding operations (assignment, import statements, for loops, with statements, exception handlers, class and<br>
function definitions).<br>
</blockquote>
<br></span>
Ah, right.  Since the PEP primarily covers comprehensions, but then went on to discuss multi-line statements, I had forgotten the comprehension part.  The answer is easy:  assignment expressions in comprehensions stay inside comprehensions, just like other inner comprehension variables already do (function sub-scope, after all).  Thank you for pointing that out.<span class=""><br></span></blockquote><div><br></div><div>That wasn't the point I was try to make: my attempted point was that I see allowing an expression like "print((f() as x), x^2, x^3)" to overwrite the regular function local "x" as being just as unacceptable as "data = [x^2 for x in sequence]" overwriting it, and we already decided that the latter was sufficiently undesirable that we were willing to break backwards compatibility in order to change it.</div><br></div>Cheers,<br></div><div class="gmail_extra">Nick.<br><br></div><div class="gmail_extra">-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>