Would there be support for a more general cmp/__cmp__

[Christopher Subich]

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.