removing list comprehensions in Python 3.0
gsakkis at rutgers.edu
Sat Jul 9 18:46:07 CEST 2005
"Raymond Hettinger" <python at rcn.com> wrote:
> In all probability, both list comprehensions and generator expressions
> will be around in perpetuity. List comps have been a very successful
> language feature.
> The root of this discussion has been the observation that a list
> comprehension can be expressed in terms of list() and a generator
No, the root of the discussion, in this thread at least, was the answer
to "why not dict comprehensions ?", which was along the lines of "well,
you can do it in one line by dict(gen_expression)".
> However, the former is faster when you actually want a
> list result and many people (including Guido) like the square brackets.
Also dict comprehensions are faster if you actually want a dict result,
set comprehensions for set result, and so on and so forth.
> After the advent of generators, it seemed for a while that all
> functions and methods that returned lists would eventually return
> iterators instead. What we are learning is that there is a place for
Altering the result type of existing functions and methods is not
exactly the same with the discussion on the future of list
comprehensions; the latter affects only whether listcomps are special
enough to be granted special syntax support, when there is an
equivalent way to express the same thing. It's funny how one of the
arguments for removing lambda -- you can do the same by defining a
named function -- does not apply for list comprehensions.
> It is darned inconvenient to get an iterator when you really
> need a list, when you want to slice the result, when you want to see a
> few elements through repr(), and when you need to loop over the
> contents more than once.
> Raymond Hettinger
Similar arguments can be given for dict comprehensions as well.
More information about the Python-list