[Python-ideas] Fast sum() for non-numbers - why so much worries?

[Joshua Landau]

On 10 July 2013 21:14, Andrew Barnert <abarnert at yahoo.com> wrote:
> [Sergey] has two versions.
>
> The first does a + once and then a += repeatedly on the result. This solves the problem neatly (except with empty iterables, but that's trivial to fix, and I think his C code actually doesn't have that problem...). There's no overhead, it automatically falls back to __add__ if __iadd__ is missing, and the only possible semantic differences are for types that are already broken.
>
> The second makes a list of the argument (which means copying it if it's already a list), then calls extend repeatedly on the result, then converts back. This doesn't solve the problem in many cases, does the wrong thing in many others, and always adds overhead.
>
> And that's exactly why I think it's worth splitting into separate pieces. It's very easy for people to see problems with the second version and wrongly assume they also apply to the first (and the way he presents and argues for his ideas doesn't help).
>
> As far as I know, nobody has yet found any problem with the first version, except for the fact that it would encourage people to use sum on lists. I don't think that's a serious problem--the docs already say not to do it--and if it's a useful optimization for any number-like types, I think it's worth having.
>
> It's the second version, together with all of the attempts to make it fully generally for any concatenable type--or, alternatively, to argue that only builtin concatenable types matter--that I have a problem with.

If Sergey doesn't do this separation, would it be fine if I did it? I
like the idea for __iadd__ sum, and I don't want Sergey block progress
on the issue.