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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
