[Python-ideas] Fast sum() for non-numbers

[Sergey]

On Jul 9, 2013 Steven D'Aprano write:

>> Well... Yes, I can! I can't make __iadd__ faster, because tuple has
>> no __iadd__, however I can make a faster __add__.
> 
> And how do you expect to do that? Tuples are immutable, you have
> to create a new tuple. So when adding a sequence of N tuples
> together, you end up making and throwing away N-1 intermediate
> results.

For example, rewrite tuple to internally store its values in a list,
and have `localcount` variable saying how many items from that list
belong to this tuple. Then __add__ could extend that list and reuse
it for new tuple. But this patch looks too complex for me,
implementing such a list storage directly in sum was much easier.

>> But as long as sum() is the only (?) function suffering from this
>> problem it was easier to do that optimization in sum() instead.
> 
> That's the big question though. Is summing a sequence of tuples
> important and common enough to justify special-casing it in sum? Just
> how many special cases can be justified?

Personally, I think this use-case is not too important. But look at
it from another perspective: is this special case is such a bad
trade-off to say in manuals:
    ...
    sum() is fast for all built-in types.
    ...

>> Looks like tuple is the only built-in type having no fast __iadd__,
> 
> I don't think so:
> [...]
> Okay, you can't sum() frozensets at all, but there's at least
> three types that support + that don't support __iadd__ (str, bytes,
> tuple), and by default anything inheriting from object will not have
> __iadd__ either.

Note, that str and bytes are rejected by sum, so again we end up with
just one type: tuple. And things inheriting from object will probably
have fast enough __add__ anyway. :)