[issue22052] Comparison operators called in reverse order for subclasses with no override.

Serhiy Storchaka added the comment: Python 2.7 is no longer supported. -- nosy: +serhiy.storchaka resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue22052] Comparison operators called in reverse order for subclasses with no override.

Mark Dickinson added the comment: > the most we should do is document the behaviour somewhere And indeed, perhaps this issue counts as sufficient documentation... -- ___ Python tracker

[issue22052] Comparison operators called in reverse order for subclasses with no override.

Mark Dickinson added the comment: For Python 2, I think the most we should do is document the behaviour somewhere; changing it in a bugfix release seems both unnecessary and potentially risky. -- ___ Python tracker

[issue22052] Comparison operators called in reverse order for subclasses with no override.

Martin Panter added the comment: Does anyone know enough about Python 2 to propose a fix? I don’t know enough about object classes versus “instance” classes, and potential interference of the __cmp__() method. In Python 2 the order seems to depend on the class type: (<__main__.A instance at

[issue22052] Comparison operators called in reverse order for subclasses with no override.

Martin Panter added the comment: My patch was committed for Python 3.4+. The priority of the comparator methods is now documented at the end of https://docs.python.org/dev/reference/datamodel.html#richcmpfuncs. Perhaps all that is left to do here is to apply similar changes to the Python 2

[issue22052] Comparison operators called in reverse order for subclasses with no override.

Martin Panter added the comment: I have included some rules about the priority for calling reflected operator methods in my patch to Issue 4395 -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22052

[issue22052] Comparison operators called in reverse order for subclasses with no override.

Mark Dickinson added the comment: the subclass provides doesn't actually imply anything about overriding, I think. Yes, that was the thrust of one of the SO answers. Unfortunately, that explanation doesn't work for arithmetic operators, though: there an explicit override is necessary.

[issue22052] Comparison operators called in reverse order for subclasses with no override.

R. David Murray added the comment: Ah yes. I remember there being a discussion somewhere about the differences between comparison operator inverses and the arithmetic 'r' methods, but I can't find it at the moment. I *thought* there was a full discussion of the logic involved in these

[issue22052] Comparison operators called in reverse order for subclasses with no override.

New submission from Mark Dickinson: As reported in a StackOverflow question [1]: the order in which the special comparison methods are called seems to be contradictory to the docs [2]. In the following snippet, __eq__ is called with reversed operands first: class A: ... def __eq__(self,

[issue22052] Comparison operators called in reverse order for subclasses with no override.

R. David Murray added the comment: the subclass provides doesn't actually imply anything about overriding, I think. For __eq__, though, that means that *every* class provides it. Indeed, I've always thought of the rule as the subclass goes first with no qualification, but that's only true