What's do list comprehensions do that generator expressions don't?

[Jeremy Bowers]

On Mon, 25 Apr 2005 16:48:46 -0400, Bill Mill wrote:

> On 25 Apr 2005 23:33:48 +0300, Ville Vainio <ville at spammers.com> wrote:

>> Still, list comprehensions should be implemented in terms of genexps to
>> get rid of the LC variable that is visible outside the scope of the LC.
>> 
>> 
> +1 . I think that we should still have the form [genexp] , but without the
> dangling variable, and implemented with generator expressions. It seems to
> me that it is inconsistent if I can do list(genexp) but not [genexp] ,
> since they are so similar. Once that happens, we can tell people who ask
> the OP's question that [genexp] is just another way to spell list(genexp),
> and he should use it if he wants the entire list constructed in memory.

This is what I meant.

Robert Kern says the implementations really differ, but I submit that
is an accident of the order they were created in, not a fundamental
constraint. list(genexp) works today and does almost exactly the same
thing, minus an optimization or two that people are working on
generalizing anyways, which is the right approach. I doubt that Python 3.0
would have two radically different implementations; they'll just have the
genexp implementation, and an optimization for list creation if the list
creation can know the size in advance, regardless of where it came from.

>>     Jeremy> should be relatively simple), it's not worth breaking that
>>     Jeremy> code.
>> 
>> Well, the code that relies on the dangling variable deserves to break.
> 
> Agreed.

This is not what I meant and I agree with it too. Breaking code depending
on variable leaking is one thing; breaking all code that uses list
comprehensions is quite another. Just because 3.0 is going to break a lot
of code anyhow doesn't mean we should be *gratuitous* about it!