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@gmail.com> wrote:
If this is portant I should probably ponder it.
On Apr 24, 2017 4:47 PM, "Stephan Hoyer" <shoyer@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@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@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)