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

[Steven D'Aprano]

On 10/07/13 16:09, Joshua Landau wrote:
> On 9 July 2013 17:13, Steven D'Aprano <steve at pearwood.info> wrote:
[...]
>> 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.

"Always"? Immutable objects cannot define __iadd__ as an in-place __add__.

In any case, sum() currently does not modify the start argument in-place.


>That makes it anything but a semantic change.

__iadd__ is optional for classes that support addition. Failure to define an __iadd__ method does not make your class broken.

Making __iadd__ mandatory to support sum would be a semantic change, since there will be objects (apart from strs and bytes, which are special-cased) that support addition with + but will no longer be summable since they don't define __iadd__.

Even making __iadd__ optional will potentially break working code. Python doesn't *require* that __iadd__ perform the same operation as __add__. That is the normal expectation, of course, but it's not enforced. (How could it be?) We might agree that objects where __add__ and __iadd__ do different things are "broken" in some sense, but you're allowed to write broken code, and Python should (in principle) avoid making it even more broken by changing behaviour unnecessarily. But maybe the right answer there is simply "don't call sum if you don't want __iadd__ called".


-- 
Steven