Re: Generator expressions v/s list comprehensions

From: Antoon Pardon (apardon_at_forel.vub.ac.be)
Date: 08/31/04 

Date: 31 Aug 2004 12:14:33 GMT

Op 2004-08-28, Alex Martelli schreef <aleaxit@yahoo.com>:
> Mahesh Padmanabhan <mahesh@privacy.net> wrote:
>
>> Hi,
>>
>> When list comprehension was added to the language, I had a lot of
>> trouble understanding it but now that I am familiar with it, I am not
>> sure how I programmed in Python without it.
>
> Oh good.
>
>>
>> Now I see that generator expressions have been added to the language
>> with 2.4 and I question the need for it. I know that it allows for lazy
>> evaluation which speeds things up for larger lists but why was it
>> necessary to add it instead of improving list comprehension?
>>
>> Was there some sort of limitation that prevented list comprehension from
>> taking over the functionality that generator expressions provide?
>
> 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.
>
>>
>> I have always liked the fact that Python has limited capabilities for
>> having more than one way to do it and it seem to me that generator
>> expressions break that philosophy. It is similar to how you have to use
>> range or xrange depending on how large the range is.
>>
>> Can someone please explain the reasoning behind 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.

The one problem I have with generator comprehensions is that, because
list comprhension came first they look like tuple comprehensions.

In order to avoid this same kind of confusion with new comers I think
it would be best if generator comprehensions are explained first and
that list comprehension is just syntax sugar for list(genexp) 

-- 
Antoon Pardon

Relevant Pages

  • Re: List Comprehension Syntax
    ... > Eric> comprehensions rather than the execution model and how to ... well, I do manipulate a few lists but more often, I manipulate ... be a iterative solution. ...
    (comp.lang.python)
  • Re: removing list comprehensions in Python 3.0
    ... both list comprehensions and generator expressions ... Also dict comprehensions are faster if you actually want a dict result, ... > functions and methods that returned lists would eventually return ...
    (comp.lang.python)
  • Re: Generator expressions v/s list comprehensions
    ... Mahesh Padmanabhan wrote: ... > Is returning a list really a limitation considering that lists can be ... >> Generator comprehensions are wonderful and there is no way Python list ... >> comprehensions and leaving only generator comprehensions, ...
    (comp.lang.python)
  • Re: Generator expressions v/s list comprehensions
    ... implies everything else. ... Is returning a list really a limitation considering that lists can be ... > comprehensions and leaving only generator comprehensions, ... I am still not clear of the advantages of using generator expressions ...
    (comp.lang.python)
  • Re: iterator wrapper
    ... This is nice but I am iterating thru hude objects so you know ... ... List comprehensions create lists, generator comprehensions create ...
    (comp.lang.python)