Antoon Pardon wrote: > If you are concerned about sorting times, I think you should > be more concerned about Guido's idea of doing away with __cmp__. > Sure __lt__ is faster. But in a number of cases writing __cmp__ > is of the same complexity as writing __lt__. So if you then > need a __lt__, __le__, __eq__, __ne__, __gt__ and __ge__ it > would be a lot easier to write a __cmp__ and have all rich > comparisons methods call this instead of duplicating the code > about six times. So you would be more or less forced to write > your class as class cld or cle. This would have a bigger > impact on sorting times than my suggestion.
Honestly, I don't really mind the idea of __cmp__ going away; for classes that behave Normally with respect to a single __cmp__ value, it's easily possible to write a CompareMixin that defines __lt__, __gt__, etc. for suitable __cmp__ values. Much like DictMixin is part of the standard library. -- http://mail.python.org/mailman/listinfo/python-list
