Eleganckie sposoby wspierania równoważności („równości”) w klasach Python

Podczas pisania klas niestandardowych często ważne jest, aby umożliwić równoważność za pomocą operatorów ==i !=. W Pythonie jest to możliwe dzięki zastosowaniu odpowiednio metod specjalnych __eq__i __ne__. Najłatwiejszym sposobem, aby to zrobić, jest następująca metoda:

class Foo:
    def __init__(self, item):
        self.item = item

    def __eq__(self, other):
        if isinstance(other, self.__class__):
            return self.__dict__ == other.__dict__
        else:
            return False

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

Czy znasz bardziej elegancki sposób na zrobienie tego? Czy znasz jakieś szczególne wady korzystania z powyższej metody porównywania __dict__?

Uwaga : Trochę wyjaśnienia - kiedy __eq__i __ne__są niezdefiniowane, znajdziesz to zachowanie:

>>> a = Foo(1)
>>> b = Foo(1)
>>> a is b
False
>>> a == b
False

Oznacza to, że a == bocenia, Falseponieważ tak naprawdę działa a is b, test tożsamości (tj. „Czy aten sam obiekt jak b?”).

Kiedy __eq__i __ne__są zdefiniowane, znajdziesz to zachowanie (którego właśnie szukamy):

>>> a = Foo(1)
>>> b = Foo(1)
>>> a is b
False
>>> a == b
True

Rozważ ten prosty problem:

class Number:

    def __init__(self, number):
        self.number = number


n1 = Number(1)
n2 = Number(1)

n1 == n2 # False -- oops

Tak więc Python domyślnie używa identyfikatorów obiektów do operacji porównania:

id(n1) # 140400634555856
id(n2) # 140400634555920

Przesłonięcie __eq__funkcji wydaje się rozwiązać problem:

def __eq__(self, other):
    """Overrides the default implementation"""
    if isinstance(other, Number):
        return self.number == other.number
    return False


n1 == n2 # True
n1 != n2 # True in Python 2 -- oops, False in Python 3

W Pythonie 2 zawsze pamiętaj o zastąpieniu __ne__funkcji, ponieważ dokumentacja stwierdza:

Nie ma żadnych domniemanych relacji między operatorami porównania. Prawda x==ynie sugeruje, że x!=yjest to fałsz. W związku z tym podczas definiowania __eq__()należy również zdefiniować, __ne__()aby operatorzy zachowywali się zgodnie z oczekiwaniami.

def __ne__(self, other):
    """Overrides the default implementation (unnecessary in Python 3)"""
    return not self.__eq__(other)


n1 == n2 # True
n1 != n2 # False

W Pythonie 3 nie jest to już konieczne, ponieważ dokumentacja stwierdza:

Domyślnie __ne__()deleguje __eq__()i odwraca wynik, chyba że tak jest NotImplemented. Nie ma innych domniemanych związków między operatorami porównania, na przykład prawda (x<y or x==y)nie implikuje x<=y.

Ale to nie rozwiązuje wszystkich naszych problemów. Dodajmy podklasę:

class SubNumber(Number):
    pass


n3 = SubNumber(1)

n1 == n3 # False for classic-style classes -- oops, True for new-style classes
n3 == n1 # True
n1 != n3 # True for classic-style classes -- oops, False for new-style classes
n3 != n1 # False

Uwaga: Python 2 ma dwa rodzaje klas:

• w stylu klasycznym (lub starym stylu ) klas, które mają nie dziedziczyć zobjecti które zostały zadeklarowane jakoclass A:,class A():lubclass A(B):gdzieBjest klasa stylu klasycznym;

• klasy w nowym stylu , które dziedzicząobjecti są zadeklarowane jakoclass A(object)lubclass A(B):gdzieBjest klasa w nowym stylu. Python 3 ma tylko klasy w nowym stylu, które są zadeklarowane jakoclass A:,class A(object):lubclass A(B):.

W przypadku klas klasycznych operacja porównania zawsze wywołuje metodę pierwszego operandu, podczas gdy w klasach nowego stylu zawsze wywołuje metodę operandu podklasy, niezależnie od kolejności operandów .

A więc, jeśli Numberjest to klasa w stylu klasycznym:

• n1 == n3połączenia n1.__eq__;
• n3 == n1połączenia n3.__eq__;
• n1 != n3połączenia n1.__ne__;
• n3 != n1połączenia n3.__ne__.

A jeśli Numberjest klasą w nowym stylu:

• zarówno n1 == n3i n3 == n1wezwanie n3.__eq__;
• zarówno n1 != n3i n3 != n1zadzwonić n3.__ne__.

Aby rozwiązać problem nieprzemienności operatorów ==i !=dla klas klasycznych języka Python 2, metody __eq__i __ne__powinny zwracać NotImplementedwartość, gdy typ argumentu nie jest obsługiwany. Dokumentacja definiuje NotImplementedwartość jako:

Metody numeryczne i metody porównywania rozszerzonego mogą zwrócić tę wartość, jeśli nie implementują operacji dla podanych argumentów. (Tłumacz interpretuje następnie operację odbicia lub inną operację zastępczą, w zależności od operatora). Jej wartość prawdy jest prawdziwa.

W tym przypadku delegaci operator operacja porównaniu do odzwierciedlenie metody z innego argumentu. W dokumentacji definiuje odzwierciedlenie metody jak:

Nie ma wersji tych metod wymiany argumentów (do użycia, gdy lewy argument nie obsługuje operacji, ale prawy argument tak;); raczej __lt__()i __gt__()są wzajemnym odbiciem, __le__()i __ge__()są wzajemnym odbiciem, __eq__()i __ne__()są ich własnym odbiciem.

Wynik wygląda następująco:

def __eq__(self, other):
    """Overrides the default implementation"""
    if isinstance(other, Number):
        return self.number == other.number
    return NotImplemented

def __ne__(self, other):
    """Overrides the default implementation (unnecessary in Python 3)"""
    x = self.__eq__(other)
    if x is NotImplemented:
        return NotImplemented
    return not x

Zwracanie NotImplementedwartości zamiast Falsejest słuszne, nawet dla klas w nowym stylu jeśli przemienność z ==i !=jest pożądane operatorów, gdy argumenty są niepowiązanych typów (bez spadku).

Czy już dotarliśmy? Nie do końca. Ile mamy unikalnych numerów?

len(set([n1, n2, n3])) # 3 -- oops

Zestawy używają skrótów obiektów, a domyślnie Python zwraca skrót identyfikatora obiektu. Spróbujmy to zastąpić:

def __hash__(self):
    """Overrides the default implementation"""
    return hash(tuple(sorted(self.__dict__.items())))

len(set([n1, n2, n3])) # 1

Wynik końcowy wygląda następująco (dodałem na końcu kilka stwierdzeń do weryfikacji):

class Number:

    def __init__(self, number):
        self.number = number

    def __eq__(self, other):
        """Overrides the default implementation"""
        if isinstance(other, Number):
            return self.number == other.number
        return NotImplemented

    def __ne__(self, other):
        """Overrides the default implementation (unnecessary in Python 3)"""
        x = self.__eq__(other)
        if x is not NotImplemented:
            return not x
        return NotImplemented

    def __hash__(self):
        """Overrides the default implementation"""
        return hash(tuple(sorted(self.__dict__.items())))


class SubNumber(Number):
    pass


n1 = Number(1)
n2 = Number(1)
n3 = SubNumber(1)
n4 = SubNumber(4)

assert n1 == n2
assert n2 == n1
assert not n1 != n2
assert not n2 != n1

assert n1 == n3
assert n3 == n1
assert not n1 != n3
assert not n3 != n1

assert not n1 == n4
assert not n4 == n1
assert n1 != n4
assert n4 != n1

assert len(set([n1, n2, n3, ])) == 1
assert len(set([n1, n2, n3, n4])) == 2

Trzeba zachować ostrożność przy dziedziczeniu:

>>> class Foo:
    def __eq__(self, other):
        if isinstance(other, self.__class__):
            return self.__dict__ == other.__dict__
        else:
            return False

>>> class Bar(Foo):pass

>>> b = Bar()
>>> f = Foo()
>>> f == b
True
>>> b == f
False

Dokładniej sprawdź typy, takie jak to:

def __eq__(self, other):
    if type(other) is type(self):
        return self.__dict__ == other.__dict__
    return False

Poza tym twoje podejście będzie działać dobrze, po to są specjalne metody.

Opisujesz sposób, w jaki zawsze to robiłem. Ponieważ jest on całkowicie ogólny, zawsze możesz podzielić tę funkcjonalność na klasę mixin i odziedziczyć ją w klasach, w których chcesz tę funkcjonalność.

class CommonEqualityMixin(object):

    def __eq__(self, other):
        return (isinstance(other, self.__class__)
            and self.__dict__ == other.__dict__)

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

class Foo(CommonEqualityMixin):

    def __init__(self, item):
        self.item = item

Nie była to bezpośrednia odpowiedź, ale wydawała się na tyle istotna, że ​​można się nią zająć, ponieważ czasami oszczędza to trochę nudnego nudy. Wytnij prosto z dokumentów ...

funkools.total_ordering (cls)

Biorąc pod uwagę klasę definiującą jedną lub więcej bogatych metod porządkowania porównań, ten dekorator klas dostarcza resztę. Upraszcza to wysiłek związany z określeniem wszystkich możliwych bogatych operacji porównania:

Klasa musi określić jeden __lt__(), __le__(), __gt__(), lub __ge__(). Ponadto klasa powinna podać __eq__()metodę.

Nowości w wersji 2.7

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

Nie musisz zastępować obu __eq__i __ne__możesz tylko zastąpić, __cmp__ale będzie to miało wpływ na wynik ==,! ==, <,> i tak dalej.

istesty tożsamości obiektu. Oznacza to, że isb będzie miało miejsce Truew przypadku, gdy oba a i b utrzymują odniesienie do tego samego obiektu. W Pythonie zawsze przechowujesz odwołanie do obiektu w zmiennej, a nie do rzeczywistego obiektu, więc w gruncie rzeczy a jest prawdą b, obiekty w nich powinny znajdować się w tym samym miejscu w pamięci. W jaki sposób i co najważniejsze, dlaczego miałby pan obchodzić to zachowanie?

Edycja: Nie wiedziałem, że __cmp__został usunięty z Pythona 3, więc unikaj go.

Z tej odpowiedzi: https://stackoverflow.com/a/30676267/541136 Udowodniłem to, chociaż poprawne jest definiowanie __ne__w kategoriach __eq__- zamiast

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

powinieneś użyć:

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

Myślę, że dwa warunki, których szukasz, to równość (==) i tożsamość (jest). Na przykład:

>>> a = [1,2,3]
>>> b = [1,2,3]
>>> a == b
True       <-- a and b have values which are equal
>>> a is b
False      <-- a and b are not the same list object

Test „jest” sprawdzi tożsamość za pomocą wbudowanej funkcji „id ()”, która zasadniczo zwraca adres pamięci obiektu, a zatem nie jest przeciążalna.

Jednak w przypadku testowania równości klasy prawdopodobnie chcesz być nieco bardziej rygorystyczny w stosunku do swoich testów i porównywać tylko atrybuty danych w swojej klasie:

import types

class ComparesNicely(object):

    def __eq__(self, other):
        for key, value in self.__dict__.iteritems():
            if (isinstance(value, types.FunctionType) or 
                    key.startswith("__")):
                continue

            if key not in other.__dict__:
                return False

            if other.__dict__[key] != value:
                return False

         return True

Ten kod będzie porównywał tylko niefunkcjonalne dane członków twojej klasy, a także pomija wszystko prywatne, co jest generalnie tym, czego chcesz. W przypadku Plain Old Python Objects mam klasę bazową, która implementuje __init__, __str__, __repr__ i __eq__, więc moje obiekty POPO nie przenoszą ciężaru całej tej dodatkowej (i w większości przypadków identycznej) logiki.

Zamiast używać subclassing / mixins, lubię używać ogólnego dekoratora klas

def comparable(cls):
    """ Class decorator providing generic comparison functionality """

    def __eq__(self, other):
        return isinstance(other, self.__class__) and self.__dict__ == other.__dict__

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

    cls.__eq__ = __eq__
    cls.__ne__ = __ne__
    return cls

Stosowanie:

@comparable
class Number(object):
    def __init__(self, x):
        self.x = x

a = Number(1)
b = Number(1)
assert a == b

Obejmuje to komentarze do odpowiedzi Algoriasa i porównuje obiekty według jednego atrybutu, ponieważ nie dbam o cały dyktando. hasattr(other, "id")musi być prawdą, ale wiem, że dzieje się tak, ponieważ ustawiłem to w konstruktorze.

def __eq__(self, other):
    if other is self:
        return True

    if type(other) is not type(self):
        # delegate to superclass
        return NotImplemented

    return other.id == self.id