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

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.

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

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

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]

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

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.

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.

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

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

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

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

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

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.