
Guido> Yes. And I'm still hoping to remove __cmp__; there should be Guido> only one way to overload comparisons.
[Andrew]
Moreover, for some data structures, the __cmp__ approach can be expensive. For example, if you're comparing sequences of any kind, and you know that the comparison is for == or !=, you have your answer immediately if the sequences differ in length. If you don't know what's being tested, as you wouldn't inside __cmp__, you may spend a lot more time to obtain a result that will be thrown away.
[Guido]
Yes. OTOH, as long as cmp() is in the language, these same situations are more efficiently done by a __cmp__ implementation than by calling __lt__ and then __eq__ or similar (it's hard to decide which order is best). So cmp() should be removed at the same time as __cmp__.
I realized the first sentence wasn't very clear. I meant that implementing cmp() is inefficient without __cmp__ for some types (especially container types). Example: cmp(range(1000)+[1], range(1000)+[0]) If the list type implements __cmp__, each of the pairs of items is compared once. OTOH, if the list type only implemented __lt__, __eq__ and __gt__, cmp() presumably would have to try one of those first, and then another one. If it picked __lt__ followed by __eq__, it would get two False results in a row, meaning it could return 1 (cmp() doesn't really expect incomparable results :-), but at the cost of comparing each pair of items twice. If cmp() picked another set of two operators to try, I'd simply adjust the example. --Guido van Rossum (home page: http://www.python.org/~guido/)