__lt__ zamiast __cmp__

Python 2.x ma dwa sposoby na przeciążenie operatorów porównania __cmp__lub „bogatych operatorów porównania”, takich jak __lt__. Mówi się, że preferowane są bogate przeciążenia porównawcze, ale dlaczego tak jest?

Bogate operatory porównania są prostsze w implementacji każdego z nich, ale musisz zaimplementować kilka z nich z prawie identyczną logiką. Jeśli jednak możesz użyć cmpporządkowania wbudowanego i krotki, to __cmp__robi się całkiem proste i spełnia wszystkie porównania:

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

Ta prostota wydaje się znacznie lepiej spełniać moje potrzeby niż przeładowanie wszystkich 6 (!) Bogatych porównań. (Jednak możesz sprowadzić to do „tylko” 4, jeśli polegasz na „zamienionym argumencie” / odzwierciedlonym zachowaniu, ale moim skromnym zdaniem powoduje to wzrost netto komplikacji).

Czy są jakieś nieprzewidziane pułapki, o których muszę wiedzieć, jeśli tylko przeciążę __cmp__?

Rozumiem <, <=, ==itp operatorzy mogą być przeciążone dla innych celów, a każdy obiekt może powrócić im się podoba. Nie pytam o zalety tego podejścia, a tylko o różnice, gdy używam tych operatorów do porównań w tym samym sensie, co dla liczb.

Aktualizacja: Jak zauważył Christopher , cmpznika w 3.x. Czy są jakieś alternatywy, które sprawiają, że wykonywanie porównań jest tak proste, jak powyższe __cmp__?

Tak, łatwo jest zaimplementować wszystko, np. __lt__Z klasą mixin (lub metaklasą, lub dekoratorem klas, jeśli tak się dzieje).

Na przykład:

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

Teraz twoja klasa może zdefiniować po prostu __lt__i pomnożyć dziedziczenie z ComparableMixin (po wszelkich innych podstawach, których potrzebuje). Dekorator klas byłby dość podobny, po prostu wstawiałby podobne funkcje jako atrybuty nowej klasy, którą dekoruje (wynik może być mikroskopijnie szybszy w czasie wykonywania, przy równie niewielkim koszcie pamięci).

Oczywiście, jeśli twoja klasa ma jakiś szczególnie szybki sposób na zaimplementowanie (np.) __eq__I __ne__powinna zdefiniować je bezpośrednio, aby wersje miksera nie były używane (na przykład, tak jest dict) - w rzeczywistości __ne__można to zdefiniować, aby ułatwić tak jak:

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

ale w powyższym kodzie chciałem zachować przyjemną symetrię tylko używania <;-). Dlaczego __cmp__musiałeś odejść, ponieważ nie mają __lt__i przyjaciele, dlaczego zachować kolejny, inny sposób to zrobić dokładnie to samo dookoła? To po prostu tak dużo martwej wagi w każdym środowisku uruchomieniowym Pythona (Classic, Jython, IronPython, PyPy, ...). Kod na pewno nie będzie zawierał błędów, to kod, którego nie ma - skąd zasada Pythona, że ​​powinien istnieć jeden oczywisty sposób wykonania zadania (C ma tę samą zasadę w sekcji „Spirit of C” w przy okazji standard ISO).

To nie znaczy, wychodzimy z naszej drodze do zakazania rzeczy (np bliskiej równoważność wstawek i klasa dekoratorów dla niektórych zastosowań), ale na pewno nie oznacza, że nie lubią nosić kod w kompilatorów i / lub środowiska wykonawcze, które istnieją nadmiarowo tylko po to, aby obsługiwać wiele równoważnych podejść do wykonania dokładnie tego samego zadania.

Dalsza edycja: w rzeczywistości istnieje jeszcze lepszy sposób na zapewnienie porównania ORAZ haszowanie dla wielu klas, w tym w pytaniu - __key__metoda, jak wspomniałem w komentarzu do pytania. Ponieważ nigdy nie udało mi się napisać dla niego PEP, musisz obecnie zaimplementować go z Mixinem (& c), jeśli chcesz:

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

Bardzo częstym przypadkiem jest, gdy porównania instancji z innymi instancjami sprowadzają się do porównania krotki dla każdego z kilkoma polami - a następnie haszowanie powinno być realizowane na dokładnie tej samej podstawie. Te __key__specjalne adresy metody, które muszą bezpośrednio.

Aby uprościć ten przypadek, istnieje dekorator klas w Pythonie 2.7 + / 3.2 +, functools.total_ordering , który może być użyty do zaimplementowania tego, co sugeruje Alex. Przykład z dokumentów:

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

Jest to objęte PEP 207 - Rich Comparisons

Ponadto __cmp__odchodzi w Pythonie 3.0. (Zauważ, że nie ma go na http://docs.python.org/3.0/reference/datamodel.html, ale jest na http://docs.python.org/2.7/reference/datamodel.html )

(Edytowano 17.06.2017 w celu uwzględnienia komentarzy).

Wypróbowałem podobną odpowiedź mixin powyżej. Wpadłem w kłopoty z „Brak”. Oto zmodyfikowana wersja, która obsługuje porównania równości z wartością „Brak”. (Nie widziałem powodu, by zawracać sobie głowę porównaniami nierówności z None jako pozbawionym semantyki):

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    

Zainspirowany ComparableMixini KeyedMixinodpowiedziami Alexa Martellego wymyśliłem następujący mixin. Umożliwia zaimplementowanie pojedynczej _compare_to()metody, która używa porównań opartych na kluczach podobnych do KeyedMixin, ale umożliwia Twojej klasie wybranie najbardziej wydajnego klucza porównania na podstawie typu other. (Zauważ, że ta mieszanka nie pomaga zbytnio w przypadku obiektów, które można przetestować pod kątem równości, ale nie porządku).

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