''.join woes - Re: max(), sum(), next()

[Boris Borcic]

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