Risposta.

Storia della questione:

In Python, il confronto degli oggetti per valore avviene tramite l'operatore '==', che internamente chiama il metodo eq. Il comportamento di questo metodo di default è ereditato da object e confronta l'identità degli oggetti (per la maggior parte delle classi).

Problema:

Quando vogliamo che le istanze delle nostre classi utente vengano confrontate in modo significativo (ad esempio, due diversi oggetti Person con lo stesso set di dati considerati uguali), il comportamento standard non è sufficiente — è necessario definire esplicitamente come avviene il confronto.

Soluzione:

Per modificare il comportamento di '==' è necessario ridefinire il metodo eq nella propria classe. Se la classe deve essere hashable, è necessario anche ridefinire hash.

Esempio di codice:

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age
    def __eq__(self, other):
        if not isinstance(other, Person):
            return NotImplemented
        return self.name == other.name and self.age == other.age
p1 = Person("Ann", 25)
p2 = Person("Ann", 25)
print(p1 == p2)  # True

Caratteristiche chiave:

• '==' chiama eq.
• Quando si confrontano oggetti senza eq verrà confrontata la loro identità (id).
• Per il corretto funzionamento con insiemi/dizionari è necessario implementare anche hash.

Domande insidiose.

Il confronto '==' è sempre simmetrico per oggetti di tipi diversi?

Non necessariamente — se il primo oggetto restituisce NotImplemented, viene chiamato il confronto inverso. Altrimenti potrebbe esserci asimmetria.

class A:
    def __eq__(self, other):
        return True
class B:
    pass
print(A() == B())  # True
print(B() == A())  # False

Se non si implementa eq, come verranno confrontati gli oggetti di una stessa classe utente?

Sarà confrontato l'id (identità in memoria, non valori degli attributi).

class Foo:
    def __init__(self, x):
        self.x = x
f1 = Foo(5)
f2 = Foo(5)
print(f1 == f2)  # False

È possibile definire eq senza hash per oggetti che devono essere chiavi in un dizionario?

No. Se eq è modificato, è anche preferibile definire hash, altrimenti l'oggetto diventerà non hashable (TypeError se usato come chiave).

class Foo:
    def __eq__(self, other):
        return True
# hash è ereditato da object, ma il comportamento sarà imprevedibile
# È meglio definire esplicitamente __hash__

Errori tipici e anti-pattern

• Implementazione di eq senza hash dove sono necessarie chiavi in dict/set.
• Errore nel confronto con oggetti di un altro tipo (deve essere restituito NotImplemented, non False).
• Definizione incoerente di eq e hash, che porta a un comportamento errato nelle strutture hash.

Esempio dalla vita reale

Caso negativo

Durante la progettazione della classe ValueObject nel team non si è tenuto conto che è stato implementato solo eq, ma non hash. Quando si tentava di utilizzare l'oggetto come chiave in un dizionario o elemento di un insieme, si generava un'eccezione TypeError.

Vantaggi:

Implementazione rapida del confronto personalizzato.

Svantaggi:

Impossibilità di utilizzare oggetti negli insiemi e nei dizionari, difficoltà nel debug.

Caso positivo

In un altro progetto, gli sviluppatori hanno chiaramente implementato entrambi i metodi — eq e hash, seguendo rigorosamente la regola: se due oggetti sono uguali in base a eq, i loro hash coincidono.

Vantaggi:

Corretto funzionamento delle strutture hash, comportamento coerente, facilità di manutenzione.

Svantaggi:

Perdita di flessibilità: oggetti uguali per valori non sono distinguibili nei contenitori hash.