On 24 March 2018 at 21:49, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 24 March 2018 at 09:18, Chris Angelico <ros...@gmail.com> wrote:
> > 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.
>
We can't do that because it would make comprehensions nigh-unusable at
class scope (or, equivalently, when using exec with a separate locals
namespace):
class C:
_sequence = "a b c d".split()
_another_sequence = [f(item) for item in _sequence]
"_sequence" needs to be resolved in the class scope and passed in as an
argument in order for that to work, as the nested scope can't see it
directly (since the implicit nested scope works like any other method
definition for name resolution purposes).
> 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).
>
PEP 572 is *mostly* immune, in that it's only the rest of the same
statement that can see the name binding.
The variant that *doesn't* introduce statement local scoping just leaks
outright into the surrounding scope.
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/
