[Python-Dev] sum(...) limitation (original) (raw)

Jim J. Jewett jimjjewett at gmail.com
Mon Aug 4 22:22:27 CEST 2014

Sat Aug 2 12:11:54 CEST 2014, Julian Taylor wrote (in https://mail.python.org/pipermail/python-dev/2014-August/135623.html ) wrote:

Andrea Griffini wrote:

However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists.

hm could this be a pure python case that would profit from temporary elision [ https://mail.python.org/pipermail/python-dev/2014-June/134826.html ]?

lists could declare the tpcanelide slot and call list.extend on the temporary during its tpadd slot instead of creating a new temporary. extend/realloc can avoid the copy if there is free memory available after the block.

Yes, with all the same problems.

When dealing with a complex object, how can you be sure that add won't need access to the original values during the entire computation? It works with matrix addition, but not with matric multiplication. Depending on the details of the implementation, it could even fail for a sort of sliding-neighbor addition similar to the original justification.

Of course, then those tricky implementations should not define an eliding_add, but maybe the builtin objects still should? After all, a plain old list is OK to re-use. Unless the first evaluation to create it ends up evaluating an item that has side effects...

In the end, it looks like a lot of machinery (and extra checks that may slow down the normal small-object case) for something that won't be used all that often.

Though it is really tempting to consider a compilation mode that assumes objects and builtins will be "normal", and lets you replace the entire above expression with compile-time [1, 2, 3, 4, 5, 6]. Would writing objects to that stricter standard and encouraging its use (and maybe offering a few AST transforms to auto-generate the out-parameters?) work as well for those who do need the speed?

-jJ

--

If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ

More information about the Python-Dev mailing list