Just a quickie - I'm out of time for now. [Guido]
That's just one of several "don't do that" situations. *What will happen* is perhaps hard to see at a glance, but it's perfectly well specified. Not all legal code does something useful though, and in this case the obvious advice should be to use different variables.
[Nick]
I can use that *exact same argument* to justify the Python 2 comprehension variable leaking behaviour. We decided that was a bad idea based on ~18 years of experience with it,
Here's the practical difference: you can't write a listcomp or genexp AT ALL without a "for" clause, so whether "for" target names leak is an issue in virtually every listcomp or genexp ever written. Here's one where it isn't: [None for somelist[12] in range(10)] Which nobody has ever seen in real life ;-) But ":=" is never required to write one - you only use it when you go out of your way to use it. I expect that will be relatively rare in real life listcomps and genexps.
and there hasn't been a clear justification presented for going back on that decision
Nobody is suggesting going back on "all and only `for` target names are local to the genexp/listcomp". To the contrary, the proposal preserves that verbatim: It's not _adding_ "oh, ya, and binding operator targets are local too". Just about everything here follows from _not_ adding that.
presented beyond "Tim would like using it sometimes".
So long as I'm the only one looking at real-life use cases, mine is the only evidence I care about ;-) I don't really care about contrived examples, unless they illustrate that a proposal is ill-defined, impossible to implement as intended, or likely to have malignant unintended consequences out-weighing their benefits.