[Python-Dev] sum(...) limitation
Stefan Behnel
stefan_ml at behnel.de
Sat Aug 2 12:56:53 CEST 2014
Julian Taylor schrieb am 02.08.2014 um 12:11:
> On 02.08.2014 08:35, Terry Reedy wrote:
>> On 8/2/2014 1:57 AM, Allen Li wrote:
>>> On Fri, Aug 01, 2014 at 02:51:54PM -0700, Guido van Rossum wrote:
>>>> No. We just can't put all possible use cases in the docstring. :-)
>>>>
>>>>
>>>> On Fri, Aug 1, 2014 at 2:48 PM, Andrea Griffini <agriff at tin.it> wrote:
>>>>
>>>> help(sum) tells clearly that it should be used to sum numbers
>>>> and not
>>>> strings, and with strings actually fails.
>>>>
>>>> However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists.
>>>>
>>>> Is this to be considered a bug?
>>>
>>> Can you explain the rationale behind this design decision? It seems
>>> terribly inconsistent. Why are only strings explicitly restricted from
>>> being sum()ed? sum() should either ban everything except numbers or
>>> accept everything that implements addition (duck typing).
>>
>> O(n**2) behavior, ''.join(strings) alternative.
>
> lists could declare the tp_can_elide slot and call list.extend on the
> temporary during its tp_add slot instead of creating a new temporary.
> extend/realloc can avoid the copy if there is free memory available
> after the block.
Yes, i.e. only sometimes. Better not rely on it in your code.
Stefan
More information about the Python-Dev
mailing list