[Python-ideas] A comprehension scope issue in PEP 572

Tim Peters tim.peters at gmail.com
Sun May 6 23:15:46 EDT 2018


[Tim]
>> There's a difference, though:  if `y` "leaks", BFD.  Who cares? ;-)
>> If `y` remains inaccessible, there's no way around that.

[Chris]
> That's Steve D'Aprano's view - why not just let them ALL leak? I don't
> like it though.

I didn't suggest that.  I'm not suggesting changing _any_ existing
behavior (quite the contrary).  Since ":=" would be brand new, there
is no existing behavior for it.

> ...
> Sorry, I meant "local to the comprehension's scope". We can't know the
> user's intention. We have to create semantics before the user's
> intention even exists.

Exactly.  That's why I would like ":-=" to be defined from the start
in a way that does least damage ;-)


>> But the point above remains:  if they don't leak, contexts that want
>> them to leak have no recourse.  If they do leak, then the other uses
>> would still work fine, but they'd possibly be annoyed by a leak they
>> didn't want.

> Then let's revert the Py3 change that put comprehensions into
> functions, and put them back to the vanilla transformation:

Again, I'm not suggesting changing any existing behavior.


> stuff = [x + 1 for x in iter if x % 3]
>
> stuff = []
> for x in iter:
>     if x % 3:
>         stuff.append(x + 1)
>
> Now 'x' leaks as well, and it's more consistent with how people
> explain comprehensions. Is that a good thing? I don't think so. Having
> the iteration variable NOT leak means it's a self-contained unit that
> simply says "that thing we're iterating over".

It's fine by me that for-target names don't leak.  I didn't suggest
changing that.


>> Part of that is because - as the existence of this thread attests to -
>> we can't even control all the scopes gimmicks Python already has.  So
>> people are understandably terrified of adding even more ;-)

> Part of it is just that people seem to be fighting for the sake of
> fighting. I'm weary of it, and I'm not going to debate this point with
> you. You want 'em to leak? No problem. Implement it that way and I'm
> not going to argue it.

I'm more interested in real-life use cases than in arguments.  My
suggestion came from staring at my real-life use cases, where binding
expressions in comprehensions would clearly be more useful if the
names bound leaked.  Nearly (but not all) of the time,, they're quite
happy with that for-target names don't leak.  Those are matters of
observation rather than of argument.


More information about the Python-ideas mailing list