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/

Reply via email to