sum and strings

[Paddy]

I was browsing the Voidspace blog item on "Flattening Lists", and
followed up on the use of sum to do the flattening.
A solution was:

>>nestedList = [[1, 2], [3, 4], [5, 6]]
sum(nestedLis t,[])

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

I would not have thought of using sum in this way. When I did help(sum)
the docstring was very number-centric: It went further, and precluded
its use on strings:

>>help(sum)

Help on built-in function sum in module __builtin__:

sum(...)
sum(sequence, start=0) -value

Returns the sum of a sequence of numbers (NOT strings) plus the
value
of parameter 'start'. When the sequence is empty, returns start.

The string preclusion would not help with duck-typing (in general), so
I decided to consult the ref doc on sum:

sum( sequence[, start])

Sums start and the items of a sequence, from left to right, and returns
the total. start defaults to 0. The sequence's items are normally
numbers, and are not allowed to be strings. The fast, correct way to
concatenate sequence of strings is by calling ''.join(sequenc e). Note
that sum(range(n), m) is equivalent to reduce(operator .add, range(n),
m) New in version 2.3.
The above was a lot better description of sum for me, and with an
inquisitive mind, I like to think that I might have come up with using
sum to flatten nestedList :-)
But there was still that warning about using strings.

I therefore tried sum versus their reduce "equivalent " for strings:

>>import operator
reduce(operat or.add, "ABCD".spli t(), '')

'ABCD'

>>sum("ABCD".sp lit(), '')

Traceback (most recent call last):
File "<interacti ve input>", line 1, in ?
TypeError: sum() can't sum strings [use ''.join(seq) instead]

>>>

Well, after all the above, there is a question:

Why not make sum work for strings too?

It would remove what seems like an arbitrary restriction and aid
duck-typing. If the answer is that the sum optimisations don't work for
the string datatype, then wouldn't it be better to put a trap in the
sum code diverting strings to the reduce equivalent?

Just a thought,

- Paddy.

[Fredrik Lundh]

Sybren Stuvel wrote:

> Why not make sum work for strings too?

Because of "there should only be one way to do it, and that way should
be obvious".

I would have thought that "performanc e" and "proper use of English" was
more relevant, though.

</F>

[Paul Rubin]

Sybren Stuvel <sy*******@YOUR thirdtower.com. imaginationwrit es:

Because of "there should only be one way to do it, and that way should
be obvious". There are already the str.join and unicode.join methods,

Those are obvious???

[Georg Brandl]

Paul Rubin wrote:

Sybren Stuvel <sy*******@YOUR thirdtower.com. imaginationwrit es:

>Because of "there should only be one way to do it, and that way should
be obvious". There are already the str.join and unicode.join methods,

Those are obvious???

Why would you try to sum up strings? Besides, the ''.join idiom is quite
common in Python.

In this special case, ''.join is much faster than sum() which is why
sum() denies to concat strings.

Georg

[bearophileHUGS]

Paul Rubin:

Sybren Stuvel:

Because of "there should only be one way to do it, and that way should
be obvious". There are already the str.join and unicode.join methods,

Those are obvious???

They aren't fully obvious (because they are methods of the separator
string), but after reading some documentation about string methods, and
after some tests done on the Python shell, you too can probably use
then without much problems.

Bye,
bearophile

[Steve Holden]

be************@ lycos.com wrote:

Paul Rubin:

>>Sybren Stuvel:

>>>Because of "there should only be one way to do it, and that way should
be obvious". There are already the str.join and unicode.join methods,

Those are obvious???

They aren't fully obvious (because they are methods of the separator
string), but after reading some documentation about string methods, and
after some tests done on the Python shell, you too can probably use
then without much problems.

Using a bound method can make it a little more obvious.

>>cat = "".join
cat(['one', 'two', 'three'])

'onetwothree'

>>cat([u'one', u'two', u'three'])

u'onetwothree'

>>>

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

[Paddy]

Sybren Stuvel wrote:

Paddy enlightened us with:

Well, after all the above, there is a question:

Why not make sum work for strings too?

Because of "there should only be one way to do it, and that way should
be obvious". There are already the str.join and unicode.join methods,
which are more powerful than sum.

Sybren

I get where you are coming from, but in this case we have a function,
sum, that is not as geeral as it could be. sum is already here, and
works for some types but not for strings which seems an arbitrary
limitation that impede duck typing.

- Pad.

P.S. I can see why, and am used to the ''.join method. A newbie
introduced to sum for integers might naturally try and concatenate
strings using sum too.

[Paddy]

Sybren Stuvel wrote:

Paddy enlightened us with:

Well, after all the above, there is a question:

Why not make sum work for strings too?

Because of "there should only be one way to do it, and that way should
be obvious". There are already the str.join and unicode.join methods,
which are more powerful than sum.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

Here is where I see the break in the 'flow':

>>1+2+3

6

>>sum([1,2,3], 0)

6

>>[1] + [2] +[3]

[1, 2, 3]

>>sum([[1],[2],[3]], [])

[1, 2, 3]

>>'1' + '2' + '3'

'123'

>>sum(['1','2','3'], '')

Traceback (most recent call last):
File "<interacti ve input>", line 1, in ?
TypeError: sum() can't sum strings [use ''.join(seq) instead]

>>>

- Pad.

[Georg Brandl]

Paddy wrote:

Sybren Stuvel wrote:

>Paddy enlightened us with:

Well, after all the above, there is a question:

Why not make sum work for strings too?

Because of "there should only be one way to do it, and that way should
be obvious". There are already the str.join and unicode.join methods,
which are more powerful than sum.

Sybren

I get where you are coming from, but in this case we have a function,
sum, that is not as geeral as it could be. sum is already here, and
works for some types but not for strings which seems an arbitrary
limitation that impede duck typing.

Only that it isn't arbitrary.

- Pad.

P.S. I can see why, and am used to the ''.join method. A newbie
introduced to sum for integers might naturally try and concatenate
strings using sum too.

Yes, and he's immediately told what to do instead.

Georg

[Fredrik Lundh]

Paddy wrote:

Here is where I see the break in the 'flow':

>>>1+2+3

6

>>>sum([1,2,3], 0)

6

>>>[1] + [2] +[3]

[1, 2, 3]

>>>sum([[1],[2],[3]], [])

[1, 2, 3]

>>>'1' + '2' + '3'

'123'

>>>sum(['1','2','3'], '')

Traceback (most recent call last):
File "<interacti ve input>", line 1, in ?
TypeError: sum() can't sum strings [use ''.join(seq) instead]

do you often write programs that "sums" various kinds of data types, and
for which performance issues are irrelevant?

or are you just stuck in a "I have this idea" loop?

</F>