On 28 March 2018 at 03:19, Guido van Rossum <gu...@python.org> wrote:
> On Tue, Mar 27, 2018 at 6:56 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>>
>> [...] The implicit functions used in the
>> comprehension & generator expression cases are just potentially
>> simpler to handle, as we don't care about their API signatures, which
>> means we can freely pollute their APIs with eager name bindings if we
>> choose to do so. [...]
>
>
> Hm, so maybe we shouldn't touch lambda, but we can at least fix the scope
> issues for comprehensions and genexprs.
Yeah, the "immediately call the function and throw it away" aspect
makes them much easier to deal with, and they're also the case that
currently feels weird to me (since the nested function is *supposed*
to be a hidden implementation detail, but it's existence currently
leaks through here).
I don't have that niggle with lambdas, since they're visibly defining
a new nested scope, so having them behave like method definitions
doesn't feel strange.
> There may still be breakage, when the code defines a global x that is
> overridden by a class-level x, and a class-level comprehension references x
> assuming it to be the global. So we need to tread carefully even here -- but
> this case is weird already:
>
> x = 42
> class C:
> x = [1, 2, 3]
> z = [x+y for y in x] # [43, 44, 45]
Hmm, potentially more concerning might be cases where methods are
currently ignored, but in a future Python start shadowing builtins for
class level comprehensions and genexps. We're getting to the level of
"rare case" (methods shadowing builtins) intersecting with "rare case"
(using a comprehension or genexp at class scope) there though, so it
should be feasible to handle through a regular deprecation cycle.
So I'd guess this would need a future import ("from __future__ import
implicit_scopes", perhaps? I'm struggling to come up with a good name,
since it's essentially "implicit comprehension and generator
expression nested scopes, version two"), and an associated deprecation
warning for free variable references that would start resolving
differently.
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/
