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

    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

    --
    Gerald Britton
     
    Gerald Britton, Feb 15, 2011
    #1
    1. Advertising

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


    --
    Steven
     
    Steven D'Aprano, Feb 15, 2011
    #2
    1. Advertising

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
    Replies:
    2
    Views:
    379
    Andrea Crotti
    Feb 15, 2011
  2. Gerald Britton

    lint warnings

    Gerald Britton, Feb 15, 2011, in forum: Python
    Replies:
    0
    Views:
    202
    Gerald Britton
    Feb 15, 2011
  3. Gerald Britton
    Replies:
    1
    Views:
    382
    Steven D'Aprano
    Feb 16, 2011
  4. David Sudolcan
    Replies:
    7
    Views:
    2,139
    Eric Sosman
    Apr 4, 2011
  5. Ted Sung
    Replies:
    1
    Views:
    331
    Sherm Pendley
    Aug 30, 2004
Loading...

Share This Page