[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-list
Subject:    Re: Would there be support for a more general cmp/__cmp__
From:       Christopher Subich <csubich.spam.block () spam ! subich ! block ! com>
Date:       2005-10-28 15:03:43
Message-ID: djtekk$f89$1 () rumours ! uwaterloo ! ca
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]