Generator expressions v/s list comprehensions

Mahesh Padmanabhan mahesh at privacy.net
Sat Aug 28 16:09:34 EDT 2004


In article <1gj8y77.6qshr41q531veN%aleaxit at yahoo.com>,
 aleaxit at yahoo.com (Alex Martelli) wrote:


> Sure, and that limitation is: list comprehensions return lists.  This
> one "limitation" (together with Python's applicative order evaluation,
> and you couldn't change THAT without breaking the whole caboodle of
> existing programs!) implies everything else.

Is returning a list really a limitation considering that lists can be 
transformed quite easily?

What is "Python's applicative order evaluation" and how do generator 
expressions get around it?


> Generator comprehensions are wonderful and there is no way Python list
> comprehensions can provide the same features, since lists need to be
> lists.  Sure, list(e(x) for x in foo) IS just the same thing as [e(x)
> for x in foo].  We'll remove the redundancy in 3.0 -- not earlier
> because it will break backwards compatibility.  The only sensible way I
> can see right now for 3.0 to remove this redundancy is by removing list
> comprehensions and leaving only generator comprehensions, btw.

I am still not clear of the advantages of using generator expressions 
(other than less memory consumption) instead of list comprehension for 
any given class of problems. Can you cite concrete use cases where 
generator expressions would be preferred over list comprehension?

Thanks,
Mahesh



More information about the Python-list mailing list