how to join array of integers?

[Summercool]

i think in Ruby, if you have an array (or list) of integers

foo = [1, 2, 3]

you can use foo.join(",") to join them into a string "1,2,3"

in Python... is the method to use ",".join() ? but then it must take
a list of strings... not integers...

any fast method?

[Marc 'BlackJack' Rintsch]

On Sat, 15 Sep 2007 12:36:02 +0000, Summercool wrote:

i think in Ruby, if you have an array (or list) of integers

foo = [1, 2, 3]

you can use foo.join(",") to join them into a string "1,2,3"

in Python... is the method to use ",".join() ? but then it must take
a list of strings... not integers...

any fast method?

Convert them to strings before joining:

In [145]: foo = [1, 2, 3]

In [146]: ','.join(map(str, foo))
Out[146]: '1,2,3'

Ciao,
Marc 'BlackJack' Rintsch

[John Machin]

On Sep 15, 10:36 pm, Summercool <[e-mail]:

i think in Ruby, if you have an array (or list) of integers

foo = [1, 2, 3]

you can use foo.join(",") to join them into a string "1,2,3"

in Python... is the method to use ",".join() ? but then it must take
a list of strings... not integers...

any fast method?

>>foo = [1,2,3]
",".join(str(x) for x in foo)

'1,2,3'

>>",".join(map(str, foo))

'1,2,3'

>>>

If you are going to write several such results to a file, consider
using the csv module.

HTH,
John

[js]

print ''.join([str(i) for i in [1,2,3]])

On 9/15/07, Summercool <Su************@gmail.comwrote:

i think in Ruby, if you have an array (or list) of integers

foo = [1, 2, 3]

you can use foo.join(",") to join them into a string "1,2,3"

in Python... is the method to use ",".join() ? but then it must take
a list of strings... not integers...

any fast method?

--
http://mail.python.org/mailman/listinfo/python-list

[Arnau Sanchez]

js escribió:

>On 9/15/07, Summercool <Su************@gmail.comwrote:

>in Python... is the method to use ",".join() ? but then it must take
a list of strings... not integers...

any fast method?

print ''.join([str(i) for i in [1,2,3]])

It's better to use generator comprehension instead of LC:

",".join(str(i) for i in [1, 2, 3])

Or, if you happen to like the itertools modules:

from itertools import imap
",".join(imap(str, [1, 2, 3]))

[Grant Edwards]

On 2007-09-15, Arnau Sanchez <ar***@ehas.orgwrote:

>>in Python... is the method to use ",".join() ? but then it
must take a list of strings... not integers...

any fast method?

print ''.join([str(i) for i in [1,2,3]])

It's better to use generator comprehension instead of LC:

",".join(str(i) for i in [1, 2, 3])

Or, if you happen to like the itertools modules:

from itertools import imap
",".join(imap(str, [1, 2, 3]))

It's nice people have invented so many ways to spell the
builting "map" ;)

>>",".join(map(str,[1,2,3]))

'1,2,3'

--
Grant Edwards grante Yow! Thousands of days of
at civilians... have produced
visi.com a... feeling for the
aesthetic modules --

[Erik Jones]

On Sep 15, 2007, at 8:56 AM, Arnau Sanchez wrote:

js escribió:

>>On 9/15/07, Summercool <Su************@gmail.comwrote:

>>in Python... is the method to use ",".join() ? but then it must
take
a list of strings... not integers...

any fast method?

>print ''.join([str(i) for i in [1,2,3]])

It's better to use generator comprehension instead of LC:

",".join(str(i) for i in [1, 2, 3])

Why is that? That entire expression must be evaluated to obtain the
result, so what is the advantage of using a generator comprehension
v. a list comprehension?

[Grant Edwards]

On 2007-09-15, Erik Jones <er**@myemma.comwrote:

>>print ''.join([str(i) for i in [1,2,3]])

It's better to use generator comprehension instead of LC:

",".join(str(i) for i in [1, 2, 3])

Why is that? That entire expression must be evaluated to obtain the
result, so what is the advantage of using a generator comprehension
v. a list comprehension?

The generator avoids creating the intermediate list -- it
generates the intermediate values on the fly. For short
sequences it probably doesn't matter much. For a very long
list it's probably noticable.

--
Grant Edwards grante Yow! Mr and Mrs PED, can I
at borrow 26.7% of the RAYON
visi.com TEXTILE production of the
INDONESIAN archipelago?

[Erik Jones]

On Sep 15, 2007, at 11:07 AM, Grant Edwards wrote:

On 2007-09-15, Arnau Sanchez <ar***@ehas.orgwrote:

>>>in Python... is the method to use ",".join() ? but then it
must take a list of strings... not integers...

any fast method?

>>print ''.join([str(i) for i in [1,2,3]])

It's better to use generator comprehension instead of LC:

",".join(str(i) for i in [1, 2, 3])

Or, if you happen to like the itertools modules:

from itertools import imap
",".join(imap(str, [1, 2, 3]))

It's nice people have invented so many ways to spell the
builting "map" ;)

>>>",".join(map(str,[1,2,3]))

'1,2,3'

IIRC, map's status as a builtin is going away.

Erik Jones

Software Developer | Emma®
er**@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com

[Eduardo O. Padoan]

It's nice people have invented so many ways to spell the

builting "map" ;)

>>",".join(map(str,[1,2,3]))

'1,2,3'

IIRC, map's status as a builtin is going away.

Actually, py3k built-in map == itertools.imap

>>map(str, [])

<itertools.imap object at 0xb7c7c9ec>

--
http://www.advogato.org/person/eopadoan/
Bookmarks: http://del.icio.us/edcrypt

[tokland]

Grant Edwards ha escrito:

Or, if you happen to like the itertools modules:

from itertools import imap
",".join(imap(str, [1, 2, 3]))

It's nice people have invented so many ways to spell the
builting "map" ;)

Did you wonder why the Python developers bother to implement "imap" if
"map" was already there?

>",".join(map(str,[1,2,3]))

'1,2,3'

Of course the result is the same, but "map" returns a list while
"itertools.imap" returns an iterator. Fortunately, "map" will become
lazy on Py3000:

http://mail.python.org/pipermail/pyt...st/009207.html

As you said, it won't be noticeable for short lists, but it's a good
programming practice to use generators instead of lists (if you don't
really need a list!)

arnau

[Robert Kern]

Grant Edwards wrote:

On 2007-09-15, Erik Jones <er**@myemma.comwrote:

>>>print ''.join([str(i) for i in [1,2,3]])
It's better to use generator comprehension instead of LC:

",".join(str(i) for i in [1, 2, 3])

Why is that? That entire expression must be evaluated to obtain the
result, so what is the advantage of using a generator comprehension
v. a list comprehension?

The generator avoids creating the intermediate list -- it
generates the intermediate values on the fly. For short
sequences it probably doesn't matter much. For a very long
list it's probably noticable.

Not true. str.join() creates a list from the iterator if it is not already a
list or a tuple. In Objects/stringobject.c, look at string_join(); it calls
PySequence_Fast() on the argument. Looking in Objects/abstract.c, we see that
PySequence_Fast() short-circuits lists and tuples but builds a full list from
the iterable otherwise.

map() seems to reliably be the fastest option, and list comprehensions seem to
slightly edge out generator comprehensions if you do the timings.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Grant Edwards]

On 2007-09-15, Robert Kern <ro*********@gmail.comwrote:

Grant Edwards wrote:

>On 2007-09-15, Erik Jones <er**@myemma.comwrote:

>>>>print ''.join([str(i) for i in [1,2,3]])
It's better to use generator comprehension instead of LC:

",".join(str(i) for i in [1, 2, 3])
Why is that? That entire expression must be evaluated to
obtain the result, so what is the advantage of using a
generator comprehension v. a list comprehension?

The generator avoids creating the intermediate list -- it
generates the intermediate values on the fly. For short
sequences it probably doesn't matter much. For a very long
list it's probably noticable.

Not true. str.join() creates a list from the iterator if it is
not already a list or a tuple.

So the iterator avoids creating an intermediate list, but the
join method goes ahead and does it anyway?

In Objects/stringobject.c, look at string_join(); it calls
PySequence_Fast() on the argument. Looking in
Objects/abstract.c, we see that PySequence_Fast()
short-circuits lists and tuples but builds a full list from
the iterable otherwise.

So what's the point of iterables if code is going to do stuff
like that when it wants to iterate over a sequence?

map() seems to reliably be the fastest option,

Which is apparently going away in favor of the slower iterator
approach?

and list comprehensions seem to slightly edge out generator
comprehensions if you do the timings.

--
Grant Edwards grante Yow! Clear the
at laundromat!! This
visi.com whirl-o-matic just had a
nuclear meltdown!!

[Steven D'Aprano]

On Sat, 15 Sep 2007 15:56:40 +0200, Arnau Sanchez wrote:

js escribió:

>>On 9/15/07, Summercool <Su************@gmail.comwrote:

>>in Python... is the method to use ",".join() ? but then it must take
a list of strings... not integers...

any fast method?

print ''.join([str(i) for i in [1,2,3]])

It's better to use generator comprehension instead of LC:

",".join(str(i) for i in [1, 2, 3])

Really? Why do you say that a generator expression is "better" than a
list comprehension?

>>import timeit
timeit.Timer("', '.join([str(i) for i in [1,2,3]])", "").repeat()

[5.0969390869140625, 4.5353701114654541, 4.5807528495788574]

>>timeit.Timer("', '.join(str(i) for i in [1,2,3])", "").repeat()

[11.651727914810181, 10.635221004486084, 10.522483110427856]

The generator expression takes about twice as long to run, and in my
opinion it is no more readable. So what's the advantage?

Or, if you happen to like the itertools modules:

from itertools import imap
",".join(imap(str, [1, 2, 3]))

>>timeit.Timer("', '.join(imap(str, [1,2,3]))",

.... "from itertools import imap").repeat()
[9.3077328205108643, 8.655829906463623, 8.5271010398864746]

Faster than a generator expression, but still pretty slow.

--
Steven.

[Steven D'Aprano]

On Sat, 15 Sep 2007 16:07:07 +0000, Grant Edwards wrote:

It's nice people have invented so many ways to spell the builting "map"
;)

>>>",".join(map(str,[1,2,3]))

'1,2,3'

The oldest solution, and if not the fastest, at least neck-and-neck with
the list comprehension.

>>timeit.Timer("', '.join(map(str, [1,2,3]))", "").repeat()

[5.0320308208465576, 4.1513419151306152, 4.0970909595489502]
For those who missed my earlier post:

list comp, best of three for one million iterations: 4.53 seconds
generator expression: 10.52 seconds
itertools.imap: 8.52 seconds

Your mileage may vary.

I think it is a crying shame that Guido's prejudice against functional
programming seems to have increased over the years, instead of decreased.
Iterators are wonderful tools, but professional tradesmen use more than
one sort of hammer. (There are claw hammers and ball peen hammers and
tack hammers and wooden mallets and...)

"One obvious way to do it" should not mean "force everyone to use a tack
hammer to drive in nails, because it's the only hammer in the tool box".
It should mean "it's obvious, use the tack hammer to drive in tacks and
the claw hammer for carpentry and the wooden mallet for beating out dints
in sheet metal and..."
--
Steven.

[Robert Kern]

Grant Edwards wrote:

On 2007-09-15, Robert Kern <ro*********@gmail.comwrote:

>Grant Edwards wrote:

>>On 2007-09-15, Erik Jones <er**@myemma.comwrote:

>print ''.join([str(i) for i in [1,2,3]])
It's better to use generator comprehension instead of LC:
>
",".join(str(i) for i in [1, 2, 3])
Why is that? That entire expression must be evaluated to
obtain the result, so what is the advantage of using a
generator comprehension v. a list comprehension?
The generator avoids creating the intermediate list -- it
generates the intermediate values on the fly. For short
sequences it probably doesn't matter much. For a very long
list it's probably noticable.

Not true. str.join() creates a list from the iterator if it is
not already a list or a tuple.

So the iterator avoids creating an intermediate list, but the
join method goes ahead and does it anyway?

Yup.

>In Objects/stringobject.c, look at string_join(); it calls
PySequence_Fast() on the argument. Looking in
Objects/abstract.c, we see that PySequence_Fast()
short-circuits lists and tuples but builds a full list from
the iterable otherwise.

So what's the point of iterables if code is going to do stuff
like that when it wants to iterate over a sequence?

Some code dealing with sequences can be recast in terms of iterators of unknown
length. Some can't. Some are better cast in terms of iterators than sequences;
some aren't.

>map() seems to reliably be the fastest option,

Which is apparently going away in favor of the slower iterator
approach?

It's only slower in this case. Of course, the main difference is where the loop
takes place, in C or in Python. imap() appears to give the same performance as
map().

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Paul Rudin]

Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:

On Sat, 15 Sep 2007 15:56:40 +0200, Arnau Sanchez wrote:

>js escribió:

>>>On 9/15/07, Summercool <Su************@gmail.comwrote:

>>>in Python... is the method to use ",".join() ? but then it must take
a list of strings... not integers...

any fast method?

> print ''.join([str(i) for i in [1,2,3]])

It's better to use generator comprehension instead of LC:

",".join(str(i) for i in [1, 2, 3])

Really? Why do you say that a generator expression is "better" than a
list comprehension?

>>>import timeit
timeit.Timer("', '.join([str(i) for i in [1,2,3]])", "").repeat()

[5.0969390869140625, 4.5353701114654541, 4.5807528495788574]

>>>timeit.Timer("', '.join(str(i) for i in [1,2,3])", "").repeat()

[11.651727914810181, 10.635221004486084, 10.522483110427856]

The generator expression takes about twice as long to run, and in my
opinion it is no more readable. So what's the advantage?

If you do it with a decent size list they take more or less the same
time. You'd presumably expect the generator to use less memory; which
might be an advantage if you have large lists.

Isn't it odd that the generator isn't faster, since the comprehension
presumably builds a list first and then iterates over it, whereas the
generator doesn't need to make a list?

[Alex Martelli]

Paul Rudin <pa*********@rudin.co.ukwrote:
...

Isn't it odd that the generator isn't faster, since the comprehension
presumably builds a list first and then iterates over it, whereas the
generator doesn't need to make a list?

The generator doesn't, but the implementation of join then does
(almost). See Objects/stringobject.c line 1745:

seq = PySequence_Fast(orig, "");

As per <http://docs.python.org/api/sequence.html>,
"""
PyObject* PySequence_Fast(PyObject *o, const char *m)

Return value: New reference.

Returns the sequence o as a tuple, unless it is already a tuple or list,
in which case o is returned. Use PySequence_Fast_GET_ITEM() to access
the members of the result. Returns NULL on failure. If the object is not
a sequence, raises TypeError with m as the message text.
"""

If orig is neither a list nor a tuple, but for example a generator,
PySequence_Fast builds a list from it (even though its docs which I just
quoted says it builds a tuple -- building the list is clearly the right
choice, so I'd say it's the docs that are wrong, not the code;-)... so
in this particular case the usual advantage of the generator disappears.

PySequence_fast is called in 13 separate spots in 8 C files in the
Python 2.5 sources, so there may a few more surprises like this;-).
Alex

[Steven D'Aprano]

On Sun, 16 Sep 2007 19:25:22 +0100, Paul Rudin wrote:

>The generator expression takes about twice as long to run, and in my
opinion it is no more readable. So what's the advantage?

If you do it with a decent size list they take more or less the same
time.

Did you try it, or are you guessing? What do you call a decent size?

You'd presumably expect the generator to use less memory; which
might be an advantage if you have large lists.

Unfortunately, Python doesn't make it as easy to measure memory use as it
does to time snippets of code, so that's just a hypothetical.

Isn't it odd that the generator isn't faster, since the comprehension
presumably builds a list first and then iterates over it, whereas the
generator doesn't need to make a list?

Who says it doesn't need to make a list? string.join() needs a sequence.
--
Steven.

[timw.google]

On Sep 15, 8:36 am, Summercool <[e-mail]:

i think in Ruby, if you have an array (or list) of integers

foo = [1, 2, 3]

you can use foo.join(",") to join them into a string "1,2,3"

in Python... is the method to use ",".join() ? but then it must take
a list of strings... not integers...

any fast method?

Isn't the OP just looking for something like:

>>foo=[1,2,3]
bar=[4,5,6]
foo+bar

[1, 2, 3, 4, 5, 6]

>>>

[John Machin]

On Sep 17, 10:16 pm, "timw.google" <[e-mail]:

On Sep 15, 8:36 am, Summercool <[e-mail]:

i think in Ruby, if you have an array (or list) of integers

foo = [1, 2, 3]

you can use foo.join(",") to join them into a string "1,2,3"

in Python... is the method to use ",".join() ? but then it must take
a list of strings... not integers...

any fast method?

Isn't the OP just looking for something like:

>foo=[1,2,3]
bar=[4,5,6]
foo+bar

[1, 2, 3, 4, 5, 6]

No. Read what he wrote. He has a SINGLE list whose elements are (e.g.)
integers [1, 2, 3], *NOT* two lists. He wants to create a STRING
"1,2,3", not a list.

[Paul Rudin]

Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:

On Sun, 16 Sep 2007 19:25:22 +0100, Paul Rudin wrote:

>>The generator expression takes about twice as long to run, and in my
opinion it is no more readable. So what's the advantage?

If you do it with a decent size list they take more or less the same
time.

Did you try it,

Yes.

or are you guessing?

Well - I guessed first, otherwise it wouldn't have been worth trying :)

What do you call a decent size?

I used 10,000.

>

>You'd presumably expect the generator to use less memory; which
might be an advantage if you have large lists.

Unfortunately, Python doesn't make it as easy to measure memory use as it
does to time snippets of code, so that's just a hypothetical.

Well - as it turns out the list gets made anyway by the join method,
so in this case there's probably little difference. However there
(obviously) are siturations where a generator is going to save you a
significant memory over the similar list comprehension.

>

>Isn't it odd that the generator isn't faster, since the comprehension
presumably builds a list first and then iterates over it, whereas the
generator doesn't need to make a list?

Who says it doesn't need to make a list? string.join() needs a sequence.

The generator doesn't make a list. The implementation of str.join does
apparently needs a sequence and so makes a list from the generator
passed to it, which is presumably why you get essentially the same
performance once you factor out setup noise for small lists.

Although it's not clear to me why the join method needs a sequence
rather than just an iterator.

[timw.google]

On Sep 17, 8:46 am, John Machin <[e-mail]:

On Sep 17, 10:16 pm, "timw.google" <[e-mail]:

On Sep 15, 8:36 am, Summercool <[e-mail]:

i think in Ruby, if you have an array (or list) of integers

foo = [1, 2, 3]

you can use foo.join(",") to join them into a string "1,2,3"

in Python... is the method to use ",".join() ? but then it must take
a list of strings... not integers...

any fast method?

Isn't the OP just looking for something like:

>>foo=[1,2,3]
>>bar=[4,5,6]
>>foo+bar

[1, 2, 3, 4, 5, 6]

No. Read what he wrote. He has a SINGLE list whose elements are (e.g.)
integers [1, 2, 3], *NOT* two lists. He wants to create a STRING
"1,2,3", not a list.- Hide quoted text -

- Show quoted text -

You're right. I read it wrong. Sorry.

[Steve Holden]

Paul Rudin wrote:

Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:

>On Sun, 16 Sep 2007 19:25:22 +0100, Paul Rudin wrote:

>>>The generator expression takes about twice as long to run, and in my
opinion it is no more readable. So what's the advantage?
If you do it with a decent size list they take more or less the same
time.

Did you try it,

Yes.

>or are you guessing?

Well - I guessed first, otherwise it wouldn't have been worth trying :)

>What do you call a decent size?

I used 10,000.

>>

>>You'd presumably expect the generator to use less memory; which
might be an advantage if you have large lists.

Unfortunately, Python doesn't make it as easy to measure memory use as it
does to time snippets of code, so that's just a hypothetical.

Well - as it turns out the list gets made anyway by the join method,
so in this case there's probably little difference. However there
(obviously) are siturations where a generator is going to save you a
significant memory over the similar list comprehension.

>>

>>Isn't it odd that the generator isn't faster, since the comprehension
presumably builds a list first and then iterates over it, whereas the
generator doesn't need to make a list?

Who says it doesn't need to make a list? string.join() needs a sequence.

The generator doesn't make a list. The implementation of str.join does
apparently needs a sequence and so makes a list from the generator
passed to it, which is presumably why you get essentially the same
performance once you factor out setup noise for small lists.

Although it's not clear to me why the join method needs a sequence
rather than just an iterator.

I suspect it's to do with making memory allocation easier, though I
didn't read the whole gory detail in stringobject.c. Without a
pre-existing set of joinable items you have to build the string up using
some sort of allocate-and-reallocate strategy, whereas if you have the
joinables already in a sequence you can pre-compute how much memory the
result will need.

Ah, right, it's in the comment:

* Do a pre-pass to figure out the total amount of space we'll
* need (sz), see whether any argument is absurd, and defer to
* the Unicode join if appropriate.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline