Hm... IIRC the reason why we did this for `__r*__` is because the more derived class might want to return an instance of that class, and we can't assume that the less derived class knows how to create an instance of the more derived class (the `__init__` signatures might differ).

For comparisons the return value is usually a bool, and in that case the type of the return value is not a concern.

But I guess for things like numpy arrays (where A<B returns an array of Booleans of the same shape) the same argument might apply. I guess it's an oversight that we didn't think of this when we added rich comparisons in PEP 207, 20 years ago. That PEP is so old it doesn't even have a date! (Hi David Ascher! :-)

I think we could try to change it but it would require a very careful risk analysis.

On Sun, Sep 27, 2020 at 1:41 PM Brett Cannon <brett@python.org> wrote:

When you do a binary arithmetic operation, one of the things that dictates whether the left-hand side's __*__ method is called before the right-hand side's __r*__ method is if the left-hand side's __r*__ differs (there's also the fact __r*__ methods are not called if. the types are the same). Presumably this is because you only care about giving precedence to the right-hand side when it would actually matter due to a difference in implementation (with the assumption that there isn't a specific need to get the right-hand side special dispensation to participate in the operation).

But with rich comparisons there doesn't seem to be an equivalent check for a difference in method implementation. Why is that? Is it because we don't want to assume that if someone bothered to implement both __gt__ and __lt__ that they would not necessarily be the inverse of each other like __add__ and __radd__?
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7NZUCODEAPQFMRFXYRMGJXDSIS3WJYIV/
Code of Conduct: http://python.org/psf/codeofconduct/