[docs] [issue12067] Doc: remove errors about mixed-type comparisons.

Terry J. Reedy report at bugs.python.org
Fri Dec 2 22:01:57 CET 2011

Terry J. Reedy <tjreedy at udel.edu> added the comment:

In Python 3, where all classes inherit from object, the default rules are, by experiment, (which someone can verify from the code) simpler than you stated.

3. By default, == and /= compare identities.
4. By default, order comparisons raise TypeError.
ob <= ob raises even though ob == ob because ob is ob.

I am not sure of the method look-up rules for rich comparisons, but perhaps the following are true:

3) with == and !=, an object is equal to itself and different objects (a is not b) compare unequal, unless the class of the first define a specific __eq__ and __ne__;

4) with <, >, <=, and >=, comparison raises a TypeError, unless the class of the first object defines specific __lt__, __gt__, __le__, and __ge__, or the class of the second defines the reflected method (__ge__ reflects __lt__, etcetera);

What is not clear to me is whether the reflected method is called if the first raises TypeError. The special method names doc (reference 3.3) says "A rich comparison method may return the singleton NotImplemented if it does not implement the operation for a given pair of arguments. 
There are no swapped-argument versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other’s reflection, __le__() and __ge__() are each other’s reflection, and __eq__() and __ne__() are their own reflection."

Does 'not supported' mean 'raises TypeError', 'returns NotImplemented', or both? If the last, I don't really understand the reason for NotImplemented versus TypeError. That point should be clarified in 3.3 also. And 3.3 should be referenced in the comparisons section.

I think point 5 should say a bit more: builtin numbers compare as expected, even when of different types; builtin sequences compare lexicographically.


Python tracker <report at bugs.python.org>

More information about the docs mailing list