[Python-ideas] Binary arithmetic does not always call subclasses first

Guido van Rossum gvanrossum at gmail.com
Tue Apr 25 12:56:19 EDT 2017


Now that I am with a real keyboard and screen and have tried to understand
the OP, I can actually write up my thoughts on the matter.

There are two aspects to the behavior. Giving preference to the class of
the right operand if it is a subclass of the left operand's class is
reasonable and explained in the docs.

Only doing this if the right operand actually overrides __rop__ was perhaps
meant as an optimization, and I expect that when I introduced that rule I
hadn't thought of the kind of classes that use type(self) or self.__class__
to return an instance of the runtime class.

However there's also another thing to consider. Consider a variant of the
OP example, where B doesn't override __add__ or __radd__, but now add a
different __init__ signature, one that requires completely different
arguments. This is entirely legal and done often enough (though perhaps not
in numpy circles?) -- constructors are not subject to the Liskov rule. So
the call to type(self)(<value>) may crash or have an undesirable result.

But given that A does call type(self)(<value>), all its subclasses have to
either have a compatible __init__ or override both __add__ and __radd__.

In the end I agree with the OP that we should fix this. I don't see a
reason to require a PEP or require updating whatever PEP described this
behavior originally -- PEPs generally describe what should be done to a
specific version of Python, they don't prevent future alterations, and they
essentially represent the historical record, not current documentation.

I'm a little worried about breaking existing code, but only a little bit,
and this is clearly a gray area, so I think it's okay to change in 3.7
without deprecations. (But I've been overruled on such matters before, so
if you disagree, speak up now and show us your code!)

--Guido

On Mon, Apr 24, 2017 at 4:54 PM, Guido van Rossum <gvanrossum at gmail.com>
wrote:

> If this is portant I should probably ponder it.
>
> On Apr 24, 2017 4:47 PM, "Stephan Hoyer" <shoyer at gmail.com> wrote:
>
>> +Georg Brandl, in case he remembers where "Move the 3k reST doc tree in
>> place." moved things from:
>> https://github.com/python/cpython/commit/116aa62bf54a39697e2
>> 5f21d6cf6799f7faa1349
>>
>> On Mon, Apr 24, 2017 at 4:29 PM, Nick Timkovich <prometheus235 at gmail.com>
>> wrote:
>>
>>> GitHub shows that that note hasn't changed in 10 years:
>>> https://github.com/python/cpython/blame/master/Doc/re
>>> ference/datamodel.rst#L2210
>>>
>>> On Mon, Apr 24, 2017 at 3:15 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>>>
>>>> On 4/24/2017 12:14 PM, Stephan Hoyer wrote:
>>>>
>>>> Based on the change in the documentation between 2.x and 3.x, I wonder
>>>>> if this is something that someone intended to clean up as part of Python
>>>>> 3000 but never got around to. I would love to hear from anyone familiar
>>>>> with the historical context here.
>>>>>
>>>>
>>>> We should ask the intention of the person who made the change, which is
>>>> in the repository.  If you email me the doc (the last part of the url) and
>>>> location within, I will look it up.
>>>>
>>>> --
>>>> Terry Jan Reedy
>>>>
>>>>
>>>> _______________________________________________
>>>> Python-ideas mailing list
>>>> Python-ideas at python.org
>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>
>>>
>>>
>>> _______________________________________________
>>> Python-ideas mailing list
>>> Python-ideas at python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170425/4d6af93b/attachment.html>


More information about the Python-ideas mailing list