<p dir="ltr">On 11 Aug 2014 22:36, "Ethan Furman" <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br>
><br>
> On 08/11/2014 02:25 PM, Nathaniel Smith wrote:<br>
>><br>
>> On Mon, Aug 11, 2014 at 10:10 PM, Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br>
>>><br>
>>> On 08/11/2014 10:53 AM, Nathaniel Smith wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> But practically speaking, how would this work? In general str.join and<br>
>>>> sum have different semantics. What happens if we descend deep into the<br>
>>>> iterable and then discover a non-string (that might nonetheless still<br>
>>>> have a + operator)?<br>
>>><br>
>>><br>
>>><br>
>>> The same thing that happens now if you pass a list to join with a non-string<br>
>>> entry:<br>
>>><br>
>>> --> ' '.join(['some', 'list', 'of', 'words', 'and', 10, 'as', 'a',<br>
>>> 'number'])<br>
>>> Traceback (most recent call last):<br>
>>>    File "<stdin>", line 1, in <module><br>
>>> TypeError: sequence item 5: expected string, int found<br>
>><br>
>><br>
>> class Nasty:<br>
>>      def __radd__(self, other):<br>
>>          return other + "foo"<br>
>><br>
>> "".join(["some", "strings", "and", "one", Nasty()])<br>
>> sum(["some", "strings", "and", "one", Nasty()], "")<br>
><br>
><br>
> Quite frankly, I regard this as a point in sum's favor.  We have, effectively, a string-subclass and join chokes on it.</p>
<p dir="ltr">Yes, but the proposal I was responding to was to do something like</p>
<p dir="ltr">def sum(it, start=0):<br>
    if start == "":<br>
        return "".join(it)<br>
    ... regular sum impl here ...</p>
<p dir="ltr">And the point is that this is not trivially a transparent optimization.</p>
<p dir="ltr">-n</p>