''.join woes - Re: max(), sum(), next()
bborcic at gmail.com
Sat Sep 13 13:06:43 CEST 2008
> Tino Wildenhain wrote:
>>> <type 'exceptions.TypeError'>: sum() can't sum strings [use
>>> ''.join(seq) instead]
>> Yes which is a bit bad anyway. I don't think hard wiring it is such a
>> nice idea. You know, walks like a duck, smells like a duck...
>> If it makes sense to handle things differently for performance, then
>> please have it doing it silently, e.g. when it detects strings just
>> use join() internally.
> ''.join is horrible. And it adds insult to injury that
> S.join(S.split(T)) != T as a rule. The interpreter has no business to
> patronize us into this shamefully contorted neighborhood while it
> understands what we want.
What makes ''.join particularly horrible is that we find ourselves forced to use
it not only for concatenating arbitrary-length strings in a list, but also to
convert to a str what's already a sequence of single characters. IOW string
types fail to satisfy a natural expectation for any S of sequence type :
S == type(S)(item for item in S) == type(S)(list(S))
And this, even though strings are sequence types deep-down-ly enough that they
achieve to act as such in far-fetched corner cases like
(lambda *x : x)(*'abc')==('a','b','c')
...and even though strings offer not one but two distinct constructors that play
nicely in back-and-forth conversions with types to which they are much less
closely related, ie.
'1j' == repr(complex('1j') == str(complex('1j'))
1j == complex(repr(1j)) == complex(str(1j))
More information about the Python-list