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 <gvanros...@gmail.com> wrote: > If this is portant I should probably ponder it. > > On Apr 24, 2017 4:47 PM, "Stephan Hoyer" <sho...@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 <prometheus...@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 <tjre...@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@python.org >>>> https://mail.python.org/mailman/listinfo/python-ideas >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>> >>> >>> >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas@python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >>> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
