I wrote:
Tino Wildenhain wrote:
[...]
sum(['a','b'],'')
<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.
Cheers
Tino
+1
''.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))
Not-so-cheerfully-yours, BB
--
http://mail.python.org/mailman/listinfo/python-list
