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

Joshua Landau joshua at landau.ws
Wed Jul 10 20:21:08 CEST 2013


On 10 July 2013 17:29, Steven D'Aprano <steve at pearwood.info> wrote:
> 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.

Now you're just (badly) playing semantics. If I say that gills are
always like lungs except they work underwater, would you contradict me
by stating that mammals don't have gills?

>> 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__.

Why are you saying these things? I never suggested anything like that.

> 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".

Python has previously had precedents where broken code does not get to
dictate the language as long as that code was very rare. This is more
than very rare. Additionally, Python does (unclearly, but it does do
so) define __iadd__ to be an inplace version of __add__, so the code
isn't just “broken” -- it's broken.


More information about the Python-ideas mailing list