Java documentation says it's strongly recommended to have them behaving consistently. But are there legitimate cases of java/c#/python/etc Object.equals() method behaving inconsistently with the method Comparable.compareTo()?
Legitimate cases of having .equals() behaving inconsistently with .compareTo()?
java;c#;object oriented;python;comparison
The reason you have two different methods is that they do two different things.The .equals method returns a boolean value indicating whether the object on which you call the method is equal to the object passed in as a parameter  (for some definition of is equal to that is consistent with the nature of the object being compared).  The .compareTo method returns a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object.  That makes it a useful method for sorting; it allows you to compare one instance with another for purposes of ordering.When the Java documentation says that these two methods must behave consistently, what they mean is that the .equals method must return true in exactly the same situations where the .compareTo method returns zero, and must return false in exactly the same situations where the .compareTo method returns a nonzero number.Is there any good reason to violate these rules?  Generally no, for the same reasons that#define TRUE FALSEis a really bad idea.  The only legitimate reason for inconsistent behavior is hinted at in the Java documentation itself: [if the] class has a natural ordering that is inconsistent with equals.To drive home the point, you can actually define .equals() in terms of compareTo(), thus guaranteeing consistent behavior.  Consider this .equals() method from a Rational class which, after a few sanity checks, simply defines .equals as compareTo() == 0:public boolean equals(Object y) {    if (y == null) return false;    if (y.getClass() != this.getClass()) return false;    Rational b = (Rational) y;    return compareTo(b) == 0;}