Lorsqu'une classe Python définit __eq__ pour personnaliser la comparaison d'égalité, l'interpréteur règle automatiquement __hash__ à None à moins d'être explicitement remplacé. Cela rend l'instance non hachable, empêchant son utilisation comme clé de dict ou membre de set. L'invariant sous-jacent exige que les objets se comparant comme égaux via __eq__ doivent produire des valeurs de hachage identiques ; violer cela provoque un comportement indéfini dans les collections basées sur le hachage. Par conséquent, tenter d'utiliser un tel objet comme clé de mapping soulève TypeError: type non hachable.
Une équipe de développement construisait un service de gestion de session où les objets User servaient de clés dans un cache en mémoire dict pour stocker des sessions actives. La classe User implémentait __eq__ pour comparer les instances en fonction de user_id, garantissant que deux objets différents représentant le même utilisateur de base de données étaient traités comme égaux. L'implémentation initiale ressemblait à ceci :
class User: def __init__(self, user_id, name): self.user_id = user_id self.name = name def __eq__(self, other): if not isinstance(other, User): return NotImplemented return self.user_id == other.user_id
Au départ, l'équipe n'avait pas implémenté __hash__, supposant que le comportement par défaut suffirait. Cependant, lorsque le service a tenté de mettre en cache une session en utilisant cache[user] = session_data, Python a levé TypeError: type non hachable: 'User', provoquant l'arrêt du service.
L'équipe a envisagé trois solutions. La première approche utilisait id(self) comme valeur de hachage. Cela a été rejeté car cela violait l'invariant critique : deux instances distinctes de User avec le même user_id auraient des hachages différents malgré le fait qu'elles soient égales via __eq__. Cela les faisait apparaître comme des clés différentes, rompant entièrement la recherche dans le cache et permettant des entrées en double pour le même utilisateur logique.
La deuxième approche utilisait hash(self.user_id) comme valeur de hachage. Cela satisfaisait l'invariant puisque les utilisateurs égaux partagent le même user_id. Cependant, cela nécessitait de s'assurer que user_id était immuable, car des valeurs de hachage mutables feraient que l'objet devienne "perdu" dans le dictionnaire si l'ID changeait après insertion.
La troisième option abandonnait l'utilisation des objets User comme clés, utilisant plutôt la chaîne user_id directement. Bien que sûre et simple, cela sacrifiait la sécurité de type et nécessitait de maintenir un mappage séparé des IDs vers les objets User, compliquant la base de code avec une logique de recherche supplémentaire.
L'équipe a choisi la deuxième solution, ajoutant l'implémentation suivante à la classe :
def __hash__(self): return hash(self.user_id)
Ils ont également fait de user_id une propriété en lecture seule pour garantir son immutabilité. Cela a préservé la capacité d'utiliser les instances de User comme clés tout en maintenant la sémantique d'égalité correcte. Le résultat était un cache robuste qui identifiait correctement les utilisateurs indépendamment de l'identité de l'instance de l'objet.
Pourquoi Python règle-t-il automatiquement __hash__ à None lorsque __eq__ est défini mais que __hash__ ne l'est pas ?
Lorsqu'une classe définit __eq__, le hachage par défaut basé sur l'identité hérité de object devient logiquement invalide. Le __hash__ par défaut repose sur id(self), ce qui signifie que deux objets distincts ont des hachages différents. Si __eq__ est remplacé pour comparer des valeurs, deux instances différentes pourraient être égales mais auraient des hachages différents, violant la règle fondamentale selon laquelle a == b implique que hash(a) == hash(b). Python empêche cette incohérence en réglant __hash__ à None, marquant explicitement la classe comme non hachable au lieu de permettre un comportement par défaut dangereux qui causerait des performances erratiques du dictionnaire ou des clés inaccessibles.
Que se passe-t-il si un objet mutable est utilisé comme clé de dictionnaire après avoir implémenté __hash__ basé sur des champs mutables ?
Si __hash__ dépend d'un état mutable, la valeur de hachage peut changer après que l'objet soit inséré dans un dict. Les dictionnaires stockent les clés dans des compartiments de hachage basés sur la valeur de hachage au moment de l'insertion. Si le hachage change ensuite en raison de la mutation, les recherches ultérieures calculent un hachage différent et recherchent un compartiment différent, rendant la clé d'origine inaccessible. L'objet reste en mémoire mais ne peut pas être trouvé ou supprimé via l'accès normal à la clé. Cela crée une fuite de mémoire et une incohérence logique, raison pour laquelle Python exige que les objets hachables soient immuables ou basés sur des identifiants immuables.
Comment le décorateur @dataclass gère-t-il la génération de __eq__ et __hash__, et quel est le risque d'utiliser unsafe_hash=True ?
Par défaut, @dataclass génère __eq__ basé sur les valeurs des champs mais règle __hash__ à None, rendant les instances non hachables. Ce défaut prudent empêche les bugs avec des dataclasses mutables. Pour activer le hachage, vous devez soit définir frozen=True (rendant les champs en lecture seule et générant un __hash__ sûr) soit définir explicitement unsafe_hash=True. Le paramètre unsafe_hash=True force Python à générer __hash__ basé sur les valeurs des champs, même si les champs sont mutables. Cela est dangereux car si un champ change après que l'objet soit utilisé comme clé de dictionnaire, le hachage change et la clé devient inaccessible, entraînant le problème de la "clé perdue" décrit précédemment. Les candidats oublient souvent que unsafe_hash n'est pas simplement un avertissement mais un risque fonctionnel qui rompt les invariants des dictionnaires.