Ensure unwanted names removed in class definition
Peter Otten
__peter__ at web.de
Fri Aug 14 02:37:30 EDT 2015
Ben Finney wrote:
> Peter Otten <__peter__ at web.de> writes:
>
>> Ben Finney wrote:
>>
>> > Peter Otten <__peter__ at web.de> writes:
>> >
>> > That's an unexpected inconsistency between list comprehensions
>> > versus generator expressions, then. Is that documented explicitly in
>> > the Python 2 documentation?
>>
>> https://docs.python.org/2.4/whatsnew/node4.html
>
> Or
> <URL:https://docs.python.org/2/whatsnew/2.4.html#pep-289-generator-expressions>.
>
> Also in the PEP that introduces generator expressions, PEP 289:
>
> List comprehensions also "leak" their loop variable into the
> surrounding scope. This will also change in Python 3.0, so that the
> semantic definition of a list comprehension in Python 3.0 will be
> equivalent to list(<generator expression>).
>
> <URL:https://www.python.org/dev/peps/pep-0289/#the-details>
>
> Thanks for seeking the answer. Can you describe an improvement to
> <URL:https://docs.python.org/2/reference/expressions.html#list-displays>
> that makes clear this unexpected, deprecated behaviour which is only in
> Python 2?
>
A sentence like that in the PEP would help, but I think the main problem is
that list comprehensions and lists are subsumed under list displays.
>From a user perspective
[f(x) for x in y]
has more in common with {x: f(x) for x in y} than with [x, y, z].
I think it would be great if list comprehensions could be moved in a
separate paragraph or into
5.2.5 Displays for [lists,] sets and dictionaries
with a note
For backwards compatibility list comprehensions leak their loop variables
into the surrounding scope. Set and dictionary displays do not leak.
I don't know if such a modification is feasible; I'm definitely no "language
lawyer".
More information about the Python-list
mailing list