[Python-Dev] sum(...) limitation (original) (raw)
Julian Taylor jtaylor.debian at googlemail.com
Sat Aug 2 12:11:54 CEST 2014
- Previous message: [Python-Dev] sum(...) limitation
- Next message: [Python-Dev] sum(...) limitation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] sum(...) limitation
- Next message: [Python-Dev] sum(...) limitation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]