This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients cvrebert, docs@python, ezio.melotti, mark.dickinson, rhettinger, terry.reedy
Date 2011-12-02.21:01:56
SpamBayes Score 1.2570112e-11
Marked as misclassified No
Message-id <>
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.
Date User Action Args
2011-12-02 21:01:57terry.reedysetrecipients: + terry.reedy, rhettinger, mark.dickinson, ezio.melotti, cvrebert, docs@python
2011-12-02 21:01:57terry.reedysetmessageid: <>
2011-12-02 21:01:56terry.reedylinkissue12067 messages
2011-12-02 21:01:56terry.reedycreate