Ensure unwanted names removed in class definition

Peter Otten __peter__ at web.de
Fri Aug 14 08:37:30 CEST 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