On Sat, Mar 24, 2018 at 10:49 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 24 March 2018 at 09:18, Chris Angelico <ros...@gmail.com> wrote: >> Except that a list comprehension is implemented using an inner >> function. Very approximately: >> >> x = [n * m for n in range(4) for m in range(5)] >> >> def <listcomp>(iter): >> ret = [] >> for n in iter: >> for m in range(5): >> ret.append(n * m) >> return ret >> x = <listcomp>(iter(range(4)) >> >> So the first (outermost) iterable is actually evaluated in the >> caller's scope, but everything else is inside a subscope. Thus an >> assignment inside that first iterable WILL leak into the surrounding >> scope; but anywhere else, it won't. > > Wow, that's subtle (in a bad way!). I'd much rather that assignments > don't leak at all - that seems to me to be the only correct design, > although I understand that implementation practicalities mean it's > hard to do. > > There's a lot of context snipped here. Is this about the variant that > just does assignment without the new scope? If it is, then is there a > similar issue with the actual proposal, or is that immune to this > problem (I suspect that it's not immune, although the details may > differ).
The code equivalence I gave above applies to the existing Python semantics. I'm not sure why the outermost iterable is evaluated in its enclosing context, but there must have been a good reason. ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
