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

Ethan Furman ethan at stoneleaf.us
Wed Jul 10 23:52:26 CEST 2013


On 07/10/2013 02:36 PM, Joshua Landau wrote:
> On 10 July 2013 22:03, Ethan Furman <ethan at stoneleaf.us> wrote:
>> On 07/10/2013 01:45 PM, Joshua Landau wrote:
>>>
>>> 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.
>>
>>
>> Make a patch and add it to the tracker.
>
> Actually, there is already a bug on the tracker at
> http://bugs.python.org/issue18305 and the response was "discuss it on
> Python-Ideas".
>
> Hence, I want to discuss it on Python ideas. So should I spawn it off
> onto a seperate thread about *just* the __iadd__ enhancement?

A separate thread on Python Ideas is probably appropriate, but you can add your __iadd__ only patch to that issue.  I 
would think it would have a better chance of acceptance since it would be a smaller change.

--
~Ethan~


More information about the Python-ideas mailing list