3 ms·

So why not just define `__eq__` and `__cmp__`. It just seems to make so much more sense... and only `__eq__` only if you need it different from `__cmp__ == 0`.

• joshuamorton 7y ago
  Because requiring you to define eq is more correct. Equality and ordering are different concepts. If they wanted to keep cmp, the only correct choice would be to require eq if you define cmp. This again goes back to what masklinn said: a total ordering across all objects in python is a misfeature. The idea that `object() < 13 < "hello world" < 3+2j < [(frozenset(), frozenset())] < {type: int}` should evaluate to anything but a TypeError is horrifying! And once you make that decision, if an object implements cmp, it must implement eq (because the safe thing should be the default, and allowing people to implement cmp in isolation lets them shoot themselves in the foot). And at that point, cmp is more work to write than le or gt, so instead just implement eq, and then if you want it, le or gt + total_ordering, or if you need weird things implement each method individually. In practice, I've also found it much easier to reason about eq or le than cmp. People like to be tricky with cmp, and even when they don't, returning -1 or 1 is less explicit than just returning True or False.
  • delaaxe 7y ago
    > The idea that `object() < 13 < "hello world" < 3+2j < [(frozenset(), frozenset())] < {type: int}` should evaluate to anything but a TypeError is horrifying! At least it evaluates to False.
    • iso-8859-1 7y ago
      Which means, that if you flip some of those operators, it will be True... Won't make sense though.