Re: Converting a list of strings into a list of integers?

Discussion in 'Python' started by Jan Riechers, Jul 22, 2012.

  1. Jan Riechers

    Jan Riechers Guest

    On 22.07.2012 18:39, Alister wrote:
    > On Sun, 22 Jul 2012 10:29:44 -0500, Tony the Tiger wrote:
    >> I came up with the following:
    >>
    >> # options.modus_list contains, e.g., "[2,3,4]"
    >> # (a string from the command line)
    >> # MODUS_LIST contains, e.g., [2,4,8,16]
    >> # (i.e., a list of integers)
    >>
    >> if options.modus_list:
    >> intTmp = []
    >> modTmp = options.modus_list[1:-1]
    >> for itm in modTmp:
    >> intTmp.append(int(itm))
    >> MODUS_LIST = intTmp
    >>
    >>
    >> TIA
    >>
    >>
    >> /Grrr

    >
    > looks like a classic list comprehension to me and can be achieved in a
    > single line
    >
    > MODUS_LIST=[int(x) for x in options.modus_list]
    >
    >
    >


    Hi,

    I am not sure why everyone is using the for-iterator option over a
    "map", but I would do it like that:

    MODUS_LIST= map(int, options.modus_list)

    "map" works on a list and does commandX (here "int" conversion, use
    "str" for string.. et cetera) on sequenceY, returning a sequence. More
    in the help file.

    And if I'm not completely mistaken, it's also the quicker way to do
    performance wise. But I can't completely recall the exact reason.

    Jan
     
    Jan Riechers, Jul 22, 2012
    #1
    1. Advertising

  2. On Sun, 22 Jul 2012 19:20:18 +0300, Jan Riechers wrote:

    > "map" works on a list and does commandX (here "int" conversion, use
    > "str" for string.. et cetera) on sequenceY, returning a sequence. More
    > in the help file.
    >
    > And if I'm not completely mistaken, it's also the quicker way to do
    > performance wise. But I can't completely recall the exact reason.


    The following only applies the standard CPython implementation. Other
    implementations may be different. In particular, PyPy turns everything
    you know about optimizing Python code on its head, and can often approach
    the speed of optimized C code in pure Python.


    map is faster than an ordinary for-loop if the function you are applying
    is a builtin like int, str, etc. But if you have to write your own pure-
    Python function, the overhead of calling a function negates the advantage
    of map, which is no faster than a for-loop. For example:

    results = map(int, sequence) # calls builtin `int`

    hoists the call to int into the fast C layer, instead of the slow Python
    layer, and should be faster than

    results = []
    for x in sequence:
    results.append(int(x))

    which runs at the speed of Python. But:

    results = map(lambda x: x+1, sequence) # calls pure Python function

    if no faster than a for-loop:

    results = []
    for x in sequence:
    results.append(x+1)

    Note: this has *nothing* to do with the use of lambda. Writing the "+1"
    function above using def instead of lambda would give the same results.

    List comprehensions are at least as fast as map, since they too hoist the
    calculation into the fast C layer. They have the added advantage that
    they can calculate arbitrarily complex Python expressions in the C layer
    without needing an intermediate function. So:

    map(lambda x: x**2 - 3, sequence)

    runs more-or-less at the speed of an ordinary for-loop, but the list
    comprehension version:

    [x**2 - 3 for x in sequence]

    should be faster and doesn't rely on an intermediate function.

    So in general, a list comprehension will be no slower than map, and may
    be faster; both will be no slower than a for-loop, and may be faster.

    Or at least, this was the case last time I checked.



    --
    Steven
     
    Steven D'Aprano, Jul 22, 2012
    #2
    1. Advertising

  3. Jan Riechers

    Jan Riechers Guest

    On 22.07.2012 20:01, Steven D'Aprano wrote:
    [SNIP]
    > map is faster than an ordinary for-loop if the function you are applying
    > is a builtin like int, str, etc. But if you have to write your own pure-
    > Python function, the overhead of calling a function negates the advantage
    > of map, which is no faster than a for-loop. For example:
    >
    > results = map(int, sequence) # calls builtin `int`
    >
    > hoists the call to int into the fast C layer, instead of the slow Python
    > layer, and should be faster than
    >
    > results = []
    > for x in sequence:
    > results.append(int(x))
    >
    > which runs at the speed of Python. But:
    >
    > results = map(lambda x: x+1, sequence) # calls pure Python function
    >
    > if no faster than a for-loop:
    >
    > results = []
    > for x in sequence:
    > results.append(x+1)
    >
    > Note: this has*nothing* to do with the use of lambda. Writing the "+1"
    > function above using def instead of lambda would give the same results.

    [SNAP]

    Hi Steven,

    besides that I testdrive Pypy (and still am impressed, other topic) -
    your answer was what I was picking for ;)

    Especially this part of you:
    > map is faster than an ordinary for-loop if the function you are applying
    > is a builtin like int, str, etc. [underlaying c-layer] But if you

    have to write your own pure-
    > Python function, the overhead of calling a function negates the advantage
    > of map [...]


    I did not know that the speed gain is up foremost present when using
    built-ins, but that's for sure something to keep in mind when writing code.

    Thanks for your explanation, clarifies a lot!

    Jan
     
    Jan Riechers, Jul 22, 2012
    #3
  4. On 2012-07-22, Jan Riechers <> wrote:

    > I am not sure why everyone is using the for-iterator option over a
    > "map", but I would do it like that:
    >
    > MODUS_LIST= map(int, options.modus_list)
    >
    > "map" works on a list and does commandX (here "int" conversion, use
    > "str" for string.. et cetera) on sequenceY, returning a sequence. More
    > in the help file.


    "map" is what comes to mind first for me, but that's probably because

    1) Before I learned Python, I learned other more functional languages
    where map was the definitive answer.

    2) When I first learned Python it didn't have list comprehensions.

    That said, "map" seems to be frowned upon by the Python community for
    reasons I've never really understood, and most people are going to
    prefer reading a list comprehension. "What most people are going to
    prefer reading" does matter...

    --
    Grant Edwards grant.b.edwards Yow! ... the MYSTERIANS are
    at in here with my CORDUROY
    gmail.com SOAP DISH!!
     
    Grant Edwards, Jul 23, 2012
    #4
  5. Jan Riechers

    rusi Guest

    On Jul 23, 7:27 pm, Grant Edwards <> wrote:

    > That said, "map" seems to be frowned upon by the Python community for
    > reasons I've never really understood,...


    Maybe the analogy:
    comprehension : map :: relational calculus : relational algebra

    In particular map, filter correspond to project and select in algebra.
    In principle the two are equivalent (Codd's theorem) however in
    practice, the calculus is found to be more declarative whereas the
    algebra is more suitable for specifying execution plans.
     
    rusi, Jul 23, 2012
    #5
    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. Roy Smith
    Replies:
    1
    Views:
    165
    Peter Otten
    Jul 22, 2012
  2. Paul Rubin
    Replies:
    0
    Views:
    161
    Paul Rubin
    Jul 22, 2012
  3. David Robinow
    Replies:
    0
    Views:
    165
    David Robinow
    Jul 22, 2012
  4. Jan Riechers
    Replies:
    0
    Views:
    153
    Jan Riechers
    Jul 22, 2012
  5. Ian Kelly
    Replies:
    0
    Views:
    135
    Ian Kelly
    Jul 22, 2012
Loading...

Share This Page