__lt__代替__cmp__

__lt__代替__cmp__

是的，很容易

__lt__

用mixin类（或元类，或者如果您以这种方式运行，则可以使用类装饰器）来实现所有内容。

例如：

class ComparableMixin:  def __eq__(self, other):    return not self<other and not other<self  def __ne__(self, other):    return self<other or other<self  def __gt__(self, other):    return other<self  def __ge__(self, other):    return not self<other  def __le__(self, other):    return not other<self

现在，您的类可以定义公正的对象，

__lt__

并从ComparableMixin继承继承（在需要任何其他基础之后，如果有的话）。一个类装饰器将是非常相似的，只是插入与其装饰的新类的属性相似的函数（结果可能在运行时在微观上更快，而在内存方面的成本也同样小）。

当然，如果您的类有一些特别快的实现方式（例如

__eq__

和）

__ne__

，则应直接定义它们，以便不使用mixin的版本（例如的情况

dict

）-实际上，

__ne__

可以将其定义为方便作为：

def __ne__(self, other):  return not self == other

但是在上面的代码中，我想保持仅使用

<

;-)的对称性。至于为什么

__cmp__

要走，既然我们 确实
有

__lt__

朋友，为什么还要用另一种不同的方法做完全一样的事情呢？在每个Python运行时（经典，Jython，IronPython，PyPy等）中，它是如此沉重。该代码
绝对 不会有虫子的是不存在的代码-
那里Python的原则是，应该是一个理想的执行任务明显的方式（C具有相同的原则的“C的精神”一节中ISO标准，顺便说一句）。

这并不意味着我们走的路，禁止的事情了（例如，混入以及一些应用类装饰之间近乎等价），但绝对 不
意味着我们不喜欢随身携带的编译器和代码/或冗余存在的运行时仅用于支持多种等效方法来执行完全相同的任务。

进一步的编辑：实际上，还有一种更好的方法可以为许多类提供比较和散列，包括问题中的那个-
一种

__key__

方法，正如我在对该问题的评论中提到的那样。由于我从来没有为它编写PEP，因此，如果愿意，您当前必须使用Mixin（＆c）来实现它：

class KeyedMixin:  def __lt__(self, other):    return self.__key__() < other.__key__()  # and so on for other comparators, as above, plus:  def __hash__(self):    return hash(self.__key__())

实例与其他实例的比较通常归结为比较每个元组和几个字段的情况，这是很常见的情况-
然后，散列应该在完全相同的基础上实现。的

__key__

直接需要特殊的方法解决。