Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #25812 > unrolled thread

Converting a list of strings into a list of integers?

Back to article view | Back to comp.lang.python

Contents

  Converting a list of strings into a list of integers? Tony the Tiger <tony@tiger.invalid> - 2012-07-22 10:29 -0500
    Re: Converting a list of strings into a list of integers? Roy Smith <roy@panix.com> - 2012-07-22 11:39 -0400
      Re: Converting a list of strings into a list of integers? Tony the Tiger <tony@tiger.invalid> - 2012-07-22 11:01 -0500
        Re: Converting a list of strings into a list of integers? Peter Otten <__peter__@web.de> - 2012-07-22 18:30 +0200
    Re: Converting a list of strings into a list of integers? Alister <alister.ware@ntlworld.com> - 2012-07-22 15:39 +0000
      Re: Converting a list of strings into a list of integers? Tony the Tiger <tony@tiger.invalid> - 2012-07-22 11:01 -0500
      Re: Converting a list of strings into a list of integers? Jan Riechers <janpeterr@freenet.de> - 2012-07-22 19:20 +0300
        Re: Converting a list of strings into a list of integers? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-22 17:01 +0000
          Re: Converting a list of strings into a list of integers? Jan Riechers <janpeterr@freenet.de> - 2012-07-22 20:27 +0300
        Re: Converting a list of strings into a list of integers? Grant Edwards <invalid@invalid.invalid> - 2012-07-23 14:27 +0000
          Re: Converting a list of strings into a list of integers? rusi <rustompmody@gmail.com> - 2012-07-23 08:31 -0700
      Re: Converting a list of strings into a list of integers? David Robinow <drobinow@gmail.com> - 2012-07-22 13:03 -0400
      Re: Converting a list of strings into a list of integers? Jan Riechers <janpeterr@freenet.de> - 2012-07-22 20:10 +0300
      Re: Converting a list of strings into a list of integers? Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-22 11:16 -0600
    Re: Converting a list of strings into a list of integers? Paul Rubin <no.email@nospam.invalid> - 2012-07-22 10:03 -0700
    Re: Converting a list of strings into a list of integers? Dave Angel <d@davea.name> - 2012-07-22 21:03 -0400

#25812 — Converting a list of strings into a list of integers?

Hi,
Is there such a thing in the language, or do I have to invent it myself?

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

There are probably never more than maybe between one to four items in the 
options.modus_list, and its contents as integers should always replace all 
of the original MODUS_LIST, because it is up to the user to decide what 
should be used for calculating the result.

The above works (unless I have introduced some bug when I copied into my 
editor here), but I would like to know if there already is such a thing, 
or something better than the above. I'd hate to re-invent the wheel.

TIA


 /Grrr
-- 
          ___                  ___
 (\_--_/)  | _ ._    _|_|_  _   |o _  _ ._
 ( 9  9 )  |(_)| |\/  |_| |(/_  ||(_|(/_|
 stripes are forever - as overripe ferrets

[toc] | [next] | [standalone]

#25813

In article <3rCdnUCiWpP1gZHNnZ2dnUVZ7vQAAAAA@giganews.com>,
 Tony the Tiger <tony@tiger.invalid> wrote:

> Hi,
> Is there such a thing in the language, or do I have to invent it myself?
> 
> 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

To answer the question you asked, to convert a list of strings to a list 
of ints, you want to do something like:

  MODUS_LIST = [int(i) for i in options.modus_list]

But, to answer the question you didn't ask, if you're trying to parse 
command-line arguments, you really want to use the argparse module.  
It's a little complicated to learn, but it's well worth the effort.

[toc] | [prev] | [next] | [standalone]

#25815

On Sun, 22 Jul 2012 11:39:30 -0400, Roy Smith wrote:

> To answer the question you asked, to convert a list of strings to a list
> of ints, you want to do something like:
> 
>   MODUS_LIST = [int(i) for i in options.modus_list]

Thanks. I'll look into that. I now remember reading about the technique 
(in Mark Lutz' "Learning Python"), but it seems I'm getting old as I tend 
to forget about it from time to time. ;)

> But, to answer the question you didn't ask, if you're trying to parse
> command-line arguments, you really want to use the argparse module. It's
> a little complicated to learn, but it's well worth the effort.

Your suggestions about the argparse. Well, it seems it does pretty much 
the same as OptionParser which I use now. Perhaps it has more features 
(that I probably won't need in my 30 line script), I only need to keep 
track of maybe one or two options. Maybe one of these days, when I have 
little else to do, or when the OptionParser stops working, I'll give it a 
try. Thanks. :)


 /Grrr
-- 
          ___                  ___
 (\_--_/)  | _ ._    _|_|_  _   |o _  _ ._
 ( 9  9 )  |(_)| |\/  |_| |(/_  ||(_|(/_|
 stripes are forever - as overripe ferrets

[toc] | [prev] | [next] | [standalone]

#25819

Tony the Tiger wrote:

> On Sun, 22 Jul 2012 11:39:30 -0400, Roy Smith wrote:
> 
>> To answer the question you asked, to convert a list of strings to a list
>> of ints, you want to do something like:
>> 
>>   MODUS_LIST = [int(i) for i in options.modus_list]
> 
> Thanks. I'll look into that. I now remember reading about the technique
> (in Mark Lutz' "Learning Python"), but it seems I'm getting old as I tend
> to forget about it from time to time. ;)
> 
>> But, to answer the question you didn't ask, if you're trying to parse
>> command-line arguments, you really want to use the argparse module. It's
>> a little complicated to learn, but it's well worth the effort.
> 
> Your suggestions about the argparse. Well, it seems it does pretty much
> the same as OptionParser which I use now. Perhaps it has more features
> (that I probably won't need in my 30 line script), I only need to keep
> track of maybe one or two options. Maybe one of these days, when I have
> little else to do, or when the OptionParser stops working, I'll give it a
> try. Thanks. :)

Here's an argparse example:

$ cat argparse_list.py
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("-m", "--modus", type=int, nargs="*")

print parser.parse_args().modus
$ python argparse_list.py 
None
$ python argparse_list.py -m
[]
$ python argparse_list.py -m 1
[1]
$ python argparse_list.py -m 1 2 3
[1, 2, 3]

[toc] | [prev] | [next] | [standalone]

#25814

On Sun, 22 Jul 2012 10:29:44 -0500, Tony the Tiger wrote:

> Hi,
> Is there such a thing in the language, or do I have to invent it myself?
> 
> 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
> 
> There are probably never more than maybe between one to four items in
> the options.modus_list, and its contents as integers should always
> replace all of the original MODUS_LIST, because it is up to the user to
> decide what should be used for calculating the result.
> 
> The above works (unless I have introduced some bug when I copied into my
> editor here), but I would like to know if there already is such a thing,
> or something better than the above. I'd hate to re-invent the wheel.
> 
> 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]



-- 
NOTICE:

-- THE ELEVATORS WILL BE OUT OF ORDER TODAY --

(The nearest working elevator is in the building across the street.)

[toc] | [prev] | [next] | [standalone]

#25816

On Sun, 22 Jul 2012 15:39:54 +0000, Alister wrote:

> 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]

Thanks, I'll look into this. See also my response to Roy Smith.


 /Grrr
-- 
          ___                  ___
 (\_--_/)  | _ ._    _|_|_  _   |o _  _ ._
 ( 9  9 )  |(_)| |\/  |_| |(/_  ||(_|(/_|
 stripes are forever - as overripe ferrets

[toc] | [prev] | [next] | [standalone]

#25818

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

[toc] | [prev] | [next] | [standalone]

#25821

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

[toc] | [prev] | [next] | [standalone]

#25827

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

[toc] | [prev] | [next] | [standalone]

#25877

On 2012-07-22, Jan Riechers <janpeterr@freenet.de> 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!!

[toc] | [prev] | [next] | [standalone]

#25891

On Jul 23, 7:27 pm, Grant Edwards <inva...@invalid.invalid> 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.

[toc] | [prev] | [next] | [standalone]

#25823

On Sun, Jul 22, 2012 at 12:20 PM, Jan Riechers <janpeterr@freenet.de> wrote:
> On 22.07.2012 18:39, Alister wrote:
>> 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.
 Because if you don't have a functional background 'map' is
unfamiliar. Although I've been aware of it for years I still can't
remember if it's map(int, list) or map(list,int) and although with a
small effort I could force it into my brain, I know that many of the
people reading my code are as ignorant as I am. The list comprehension
seems clearer to me.

[toc] | [prev] | [next] | [standalone]

#25824

On 22.07.2012 20:03, David Robinow wrote:
> On Sun, Jul 22, 2012 at 12:20 PM, Jan Riechers <janpeterr@freenet.de> wrote:
>> On 22.07.2012 18:39, Alister wrote:
>>> 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.
>   Because if you don't have a functional background 'map' is
> unfamiliar. Although I've been aware of it for years I still can't
> remember if it's map(int, list) or map(list,int) and although with a
> small effort I could force it into my brain, I know that many of the
> people reading my code are as ignorant as I am. The list comprehension
> seems clearer to me.
>
>

Hello,

no offense by that, I just was wondering why everyone uses the list 
comprehension instead the built-in map in this case - I'm still using 
Python 2.7.3 so perhaps things might have changed a little. :)

So far
Jan

[toc] | [prev] | [next] | [standalone]

#25825

On Sun, Jul 22, 2012 at 10:20 AM, Jan Riechers <janpeterr@freenet.de> wrote:
> 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.

My recollection is that map has the edge if you can pass it a built-in
or a C extension function, like int, or a complicated Python function
that you would end up calling anyway in the list comprehension.  The
situation changes though if you can write the comprehension to remove
the overhead of the Python function call.  For example:

map(lambda x: x+1, my_list)

[x+1 for x in my_list]

By performing the addition inline instead of calling a function to do
it, the list comprehension wins performance-wise in this scenario.  So
as a simple rule of thumb I will typically choose between map or a
comprehension based on whether I need to call a function or not (and
also based on how pretty or ugly the resulting code is).  Anything
further would just be premature optimization.  Also keep in mind that
in Python 3 map returns an iterator instead of a list, so for a fair
comparison you would have to compose the map with a list() call.

Cheers,
Ian

[toc] | [prev] | [next] | [standalone]

#25822

Tony the Tiger <tony@tiger.invalid> writes:
> # options.modus_list contains, e.g., "[2,3,4]"

Try this:

    import ast
    MODUS_LIST = ast.literal_eval(options.modus_list)

literal_eval is like eval except it can only evaluate literals rather
than calling functions and the like.  The idea is you can use it on
untrusted data.

[toc] | [prev] | [next] | [standalone]

#25835

On 07/22/2012 11:29 AM, Tony the Tiger wrote:
> Hi,
> Is there such a thing in the language, or do I have to invent it myself?
>
> I came up with the following:
>
> # options.modus_list contains, e.g., "[2,3,4]"
> #	(a string from the command line)
> <SNIP>
>
>
>

So which is it, a list of strings, or a string?  Your subject line does
not agree with the comment.

-- 

DaveA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web