[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!)
On Mon, Apr 24, 2017 at 4:54 PM, Guido van Rossum <gvanrossum at gmail.com>
> 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:
>> On Mon, Apr 24, 2017 at 4:29 PM, Nick Timkovich <prometheus235 at gmail.com>
>>> GitHub shows that that note hasn't changed in 10 years:
>>> 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
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>> Python-ideas mailing list
>>> Python-ideas at python.org
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>> Python-ideas mailing list
>> Python-ideas at python.org
>> Code of Conduct: http://python.org/psf/codeofconduct/
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas