[Python-Dev] sum(...) limitation
Julian Taylor
jtaylor.debian at googlemail.com
Sat Aug 2 12:11:54 CEST 2014
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.
>
>
hm could this be a pure python case that would profit from temporary
elision [0]?
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.
[0] https://mail.python.org/pipermail/python-dev/2014-June/134826.html
More information about the Python-Dev
mailing list