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

[Ethan Furman]

On 07/09/2013 11:09 PM, Joshua Landau wrote:
> On 9 July 2013 17:13, Steven D'Aprano <steve at pearwood.info> wrote:
>> On 09/07/13 19:35, Sergey wrote:
>>>
>>> On Jul 5, 2013 Stefan Behnel wrote:
>>>
>>>> No, please. Using sum() on lists is not more than a hack that
>>>> seems to be a cool idea but isn't. Seriously - what's the sum of
>>>> lists? Intuitively, it makes no sense at all to say sum(lists).
>>>
>>>
>>> It's the same as it is now. What else can you think about when you
>>> see: [1, 2, 3] + [4, 5] ?
>>
>>
>> Some of us think that using + for concatenation is an abuse of terminology,
>> or at least an unfortunate choice of operator, and are wary of anything that
>> encourages that terminology.
>>
>> Nevertheless, you are right, in Python 3 both + and sum of lists is
>> well-defined. At the moment sum is defined in terms of __add__. You want to
>> change it to be defined in terms of __iadd__. That is a semantic change that
>> needs to be considered carefully, it is not just an optimization.
>
> I agree it's not totally backward-compatible, but AFAICT that's only
> for broken code. __iadd__ should always just be a faster, in-place
> __add__ and so this change should never cause problems in properly
> written code. That makes it anything but a semantic change. It's the
> same way people discuss the order of __hash__ calls on updates to code
> but no-one calls it a *semantics* change.

Currently, sum() does not modify its arguments.

You (or whoever) are suggesting that it should modify one of them.

That makes it a semantic change, and a bad one.

-1

--
~Ethan~