lint warnings

Discussion in 'Python' started by Gerald Britton, Feb 15, 2011.

  1. 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.
    >>> del item

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    NameError: name 'item' is not defined
    >>> [int(item) for item in range(10)]

    [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
    >>> item


    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

    Gerald Britton
    Gerald Britton, Feb 15, 2011
    1. Advertisements

  2. On Tue, 15 Feb 2011 14:32:13 +0000, Duncan Booth wrote:

    > <snip>
    >> Also, as already shown, the map version is faster.

    > 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\ -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\ -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.


    Steven D'Aprano, Feb 15, 2011
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrea Crotti

    lint warnings

    Andrea Crotti, Feb 14, 2011, in forum: Python
    Andrea Crotti
    Feb 15, 2011
  2. Gerald Britton

    lint warnings

    Gerald Britton, Feb 15, 2011, in forum: Python
    Gerald Britton
    Feb 15, 2011
  3. Gerald Britton
    Steven D'Aprano
    Feb 16, 2011
  4. David Sudolcan
    Eric Sosman
    Apr 4, 2011
  5. Ted Sung
    Sherm Pendley
    Aug 30, 2004

Share This Page