__lt__ en lugar de __cmp__

Python 2.x tiene dos formas de sobrecargar los operadores de comparación, __cmp__o los "operadores de comparación enriquecidos" como __lt__. Se dice que se prefieren las abundantes sobrecargas de comparación, pero ¿por qué es así?

Los operadores de comparación ricos son más simples de implementar cada uno, pero debe implementar varios de ellos con una lógica casi idéntica. Sin embargo, si puede usar el orden integrado cmpy de tuplas, entonces se __cmp__vuelve bastante simple y cumple con todas las comparaciones:

class A(object):
  def __init__(self, name, age, other):
    self.name = name
    self.age = age
    self.other = other
  def __cmp__(self, other):
    assert isinstance(other, A) # assumption for this example
    return cmp((self.name, self.age, self.other),
               (other.name, other.age, other.other))

Esta simplicidad parece satisfacer mis necesidades mucho mejor que sobrecargar las 6 (!) De las ricas comparaciones. (Sin embargo, puede reducirlo a "solo" 4 si confía en el "argumento intercambiado" / comportamiento reflejado, pero eso da como resultado un aumento neto de complicaciones, en mi humilde opinión).

¿Hay problemas imprevistos de los que deba ser consciente si solo sobrecargo __cmp__?

Entiendo la <, <=, ==, etc. operadores pueden ser sobrecargados para otros fines, y puede devolver cualquier objeto que les gusta. No estoy preguntando sobre los méritos de ese enfoque, sino solo sobre las diferencias al usar estos operadores para comparaciones en el mismo sentido en que se refieren a los números.

Actualización: como señaló Christopher , cmpestá desapareciendo en 3.x. ¿Existen alternativas que faciliten la implementación de comparaciones como las anteriores __cmp__?

Sí, es fácil implementar todo en términos de, por ejemplo, __lt__con una clase mixin (o una metaclase, o un decorador de clases si su gusto es así).

Por ejemplo:

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

Ahora su clase puede definir __lt__heredar solo y multiplicar de ComparableMixin (después de cualquier otra base que necesite, si corresponde). Un decorador de clases sería bastante similar, simplemente insertando funciones similares como atributos de la nueva clase que está decorando (el resultado podría ser microscópicamente más rápido en tiempo de ejecución, con un costo igualmente mínimo en términos de memoria).

Por supuesto, si su clase tiene alguna forma particularmente rápida de implementar (por ejemplo) __eq__y __ne__, debe definirlas directamente para que las versiones de mixin no se utilicen (por ejemplo, ese es el caso dict); de hecho, __ne__podría definirse para facilitar Eso es todo:

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

pero en el código anterior quería mantener la agradable simetría de solo usar <;-). En cuanto a por qué __cmp__tenía que ir, ya que lo hizo tener __lt__y amigos, ¿por qué mantener a la otra, diferente manera de hacer exactamente lo mismo que en todo? Es un peso muerto en cada tiempo de ejecución de Python (Classic, Jython, IronPython, PyPy, ...). El código que definitivamente no tendrá errores es el código que no está allí, de ahí el principio de Python de que idealmente debería haber una forma obvia de realizar una tarea (C tiene el mismo principio en la sección "Espíritu de C" de el estándar ISO, por cierto).

Esto no quiere decir que vayamos fuera de nuestro camino para prohibir las cosas (por ejemplo, cerca de la equivalencia entre mixins y decoradores de clase para algunos usos), pero definitivamente hace media que no nos gusta llevar alrededor de código en los compiladores y / o tiempos de ejecución que existen de forma redundante solo para admitir múltiples enfoques equivalentes para realizar exactamente la misma tarea.

Edición adicional: en realidad, hay una manera aún mejor de proporcionar comparación Y hash para muchas clases, incluido eso en la pregunta: un __key__método, como mencioné en mi comentario a la pregunta. Como nunca llegué a escribir el PEP para él, actualmente debe implementarlo con un Mixin (& c) si le gusta:

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__())

Es un caso muy común que las comparaciones de una instancia con otras instancias se reduzcan a comparar una tupla para cada una con unos pocos campos, y luego, el hash debe implementarse exactamente sobre la misma base. El __key__método especial aborda esa necesidad directamente.

Para simplificar este caso, hay un decorador de clases en Python 2.7 + / 3.2 +, functools.total_ordering , que se puede usar para implementar lo que sugiere Alex. Ejemplo de los documentos:

@total_ordering
class Student:
    def __eq__(self, other):
        return ((self.lastname.lower(), self.firstname.lower()) ==
                (other.lastname.lower(), other.firstname.lower()))
    def __lt__(self, other):
        return ((self.lastname.lower(), self.firstname.lower()) <
                (other.lastname.lower(), other.firstname.lower()))

Esto está cubierto por PEP 207 - Comparaciones enriquecidas

Además, __cmp__desaparece en Python 3.0. (Tenga en cuenta que no está presente en http://docs.python.org/3.0/reference/datamodel.html pero está en http://docs.python.org/2.7/reference/datamodel.html )

(Editado el 17/6/17 para tener en cuenta los comentarios).

Probé la respuesta de mezcla comparable anterior. Me metí en problemas con "Ninguno". Aquí hay una versión modificada que maneja comparaciones de igualdad con "Ninguno". (No vi ninguna razón para molestarme con las comparaciones de desigualdad con Ninguno por carecer de semántica):

class ComparableMixin(object):

    def __eq__(self, other):
        if not isinstance(other, type(self)): 
            return NotImplemented
        else:
            return not self<other and not other<self

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

    def __gt__(self, other):
        if not isinstance(other, type(self)): 
            return NotImplemented
        else:
            return other<self

    def __ge__(self, other):
        if not isinstance(other, type(self)): 
            return NotImplemented
        else:
            return not self<other

    def __le__(self, other):
        if not isinstance(other, type(self)): 
            return NotImplemented
        else:
            return not other<self    

Inspirado por Alex Martelli de ComparableMixiny KeyedMixinrespuestas, se me ocurrió la siguiente mixin. Le permite implementar un solo _compare_to()método, que utiliza comparaciones basadas en claves similares a KeyedMixin, pero permite que su clase elija la clave de comparación más eficiente según el tipo de other. (Tenga en cuenta que este mixin no ayuda mucho para los objetos que se pueden probar para la igualdad pero no el orden).

class ComparableMixin(object):
    """mixin which implements rich comparison operators in terms of a single _compare_to() helper"""

    def _compare_to(self, other):
        """return keys to compare self to other.

        if self and other are comparable, this function 
        should return ``(self key, other key)``.
        if they aren't, it should return ``None`` instead.
        """
        raise NotImplementedError("_compare_to() must be implemented by subclass")

    def __eq__(self, other):
        keys = self._compare_to(other)
        return keys[0] == keys[1] if keys else NotImplemented

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

    def __lt__(self, other):
        keys = self._compare_to(other)
        return keys[0] < keys[1] if keys else NotImplemented

    def __le__(self, other):
        keys = self._compare_to(other)
        return keys[0] <= keys[1] if keys else NotImplemented

    def __gt__(self, other):
        keys = self._compare_to(other)
        return keys[0] > keys[1] if keys else NotImplemented

    def __ge__(self, other):
        keys = self._compare_to(other)
        return keys[0] >= keys[1] if keys else NotImplemented