On 24 March 2018 at 09:18, Chris Angelico <ros...@gmail.com> wrote: > On Sat, Mar 24, 2018 at 8:07 PM, Christoph Groth > <christ...@grothesque.org> wrote: >> Chris Angelico wrote: >> >>> Thank you; both of these have now been incorporated into the document. >> >> Thanks! Just a small comment. You wrote in the PEP draft: >> >>> # Name bindings inside list comprehensions usually won't leak >>> ... >>> # But occasionally they will! >> >> I don't understand what you mean here. If the (y as x) syntax is to >> have, as you say, "the exact same semantics as regular assignment", then >> assignments inside list comprehensions would always "leak". But this is >> a good thing, because this is consistent with how Python behaves. > > 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). Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
