On 3 March 2018 at 03:51, Ethan Furman <et...@stoneleaf.us> wrote: > On 03/02/2018 02:47 AM, Nick Coghlan wrote: > >> On 2 March 2018 at 16:39, Ethan Furman wrote: >> >>> On 03/01/2018 09:08 PM, Nick Coghlan wrote: >>> >> > Adding statement local variables into that mix *without* some form of >>>> syntactic marker would mean taking an already >>>> complicated system, and making it even harder to reason about correctly >>>> (especially if statement locals interact >>>> with nested scopes differently from the way other locals in the same >>>> scope do). >>>> >>> >>> Seems like it would far easier and (IMHO) more useful to scale the >>> proposal back from a statement scope to simple >>> expression assignment, and the variable is whatever scope it would have >>> been if assigned to outside the expression >>> (default being local, but non-local or global if already declared as >>> such). >>> >> >> Because that would put us back in the exact same problematic situation we >> had when "[x*x for x in sequence]" leaked the >> iteration variable (only worse): no function locals would be safe, since >> arbitrary expressions could clobber them, not >> just name binding operations (assignment, import statements, for loops, >> with statements, exception handlers, class and >> function definitions). >> > > 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. >
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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
