Home Original page

[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