lint warnings

[Gerald Britton]

I find:

map(func, iterable)

to be "neater" than:

[func(item) for item in iterable]

If nothing else, the "map" version is shorter. More importantly, in
the 2.x series (which I am often limited to for compatibility
reasons), the variable used in the list comprehension leaks to the
following code:

$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):

[int(item) for item in range(10)] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
item 9

which can cause hard-to-find bugs. Fortunately this has been corrected in 3.x.

Also, as already shown, the map version is faster. BTW, if you like:

[item for item in iterable if predicate(item)]

you can use:

filter(predicate, item)

I find the latter neater for the same reasons as above

 

[Steven D'Aprano]

In most cases the list comprehension is faster. Try timing it.

For an extremely specialised and minimal definition of "most cases".

C:\Python27>python.exe lib\timeit.py -s "def double(x): return x*2" -s
"data=range(10000)" "map(double, data)" 1000 loops, best of 3: 1.82 msec
per loop

C:\Python27>python.exe lib\timeit.py -s "def double(x): return x*2" -s
"data=range(10000)" "[x*2 for x in data]" 1000 loops, best of 3: 879
usec per loop

You're not comparing apples and apples. Try calling the function double()
from the list comp, instead of inlining it.

Yes, if you can avoid a function call, list comps are faster than map.
That's a valuable micro-optimization, although the warning about
premature optimizations and small efficiencies apply. But the number of
operations that can be inlined is only a vanishingly small subset of all
operations you might choose to perform, and in general, map is faster
than list comps with both C built-ins and pure Python functions.

There's no doubt that list comps are a moderate win for readability and
speed when you can inline the function as opposed to defining a lambda
inside the map. But otherwise, it's a myth that map is generally slower
and longer than list comps. It's usually the other way around:

map(function, data)
[function(x) for x in data]

Even in Python3 where map becomes an iterator, it's still shorter:

list(map(function, data))
[function(x) for x in data]

(by two whole characters! Woo hoo, I don't need to upgrade my hard
drive!!! *wink*)

Conceptually, a map is a single operation. You don't have to think about
the implementation, namely, "iterate over the sequence, extracting each
item into a temporary variable, and call the function on that temporary
variable". You just map the function to the sequence, and don't worry
about the implementation. I really appreciate that. Sometimes I wish that
Python would let me write function(data), although given that this would
be ambiguous, map is the next best thing.

map is only likely to be faster if you wanted to call a function in both
cases. If you have an expression that can be inlined you save the
function call overhead with the list comprehension.

Exactly.