Ответ на вопрос

Когда класс Python определяет __eq__ для настройки сравнения на равенство, интерпретатор автоматически устанавливает __hash__ в None, если не переопределить его явно. Это делает экземпляр не хэшируемым, что препятствует его использованию в качестве ключа в dict или члена set. Основное инвариантное требование состоит в том, что объекты, которые сравниваются как равные через __eq__, должны давать идентичные хэш-значения; нарушение этого приводит к неопределенному поведению в коллекциях, основанных на хэшах. В результате попытка использовать такой объект в качестве ключа в отображении вызывает TypeError: unhashable type.

Ситуация из жизни

Команда разработчиков создавала сервис управления сессиями, где объекты User служили ключами в кэше dict для хранения активных сессий. Класс User реализовал __eq__, чтобы сравнивать экземпляры по user_id, гарантируя, что два различных объекта, представляющих одного и того же пользователя из базы данных, считались равными. Первоначальная реализация выглядела так:

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

Сначала команда не реализовала __hash__, предполагая, что поведение по умолчанию будет достаточным. Однако когда сервис попытался кэшировать сессию, используя cache[user] = session_data, Python вызвал TypeError: unhashable type: 'User', что привело к сбою сервиса.

Команда рассмотрела три решения. Первый подход использовал id(self) в качестве хэш-значения. Этот вариант был отвергнут, потому что он нарушал важнейшее инвариантное требование: два различных экземпляра User с одинаковым user_id имели бы разные хэши, несмотря на то, что они были равны через __eq__. Это привело бы к тому, что они выглядели бы как разные ключи, полностью нарушая поиск в кэше и позволяя дублировать записи для одного и того же логического пользователя.

Второй подход использовал hash(self.user_id) в качестве хэш-значения. Это удовлетворяло инварианту, поскольку равные пользователи делят одно и то же user_id. Однако это требовало обеспечения неизменности user_id, так как изменяемые хэш-значения привели бы к тому, что объект "утерялся" в словаре, если ID изменился после вставки.

Третий вариант отказался от использования объектов User в качестве ключей, вместо этого использовав строку user_id напрямую. Хотя это было безопасно и просто, это жертвовало типобезопасностью и требовало поддержания отдельного отображения от ID к объектам User, что усложняло кодовую базу дополнительной логикой поиска.

Команда выбрала второе решение, добавив следующую реализацию в класс:

    def __hash__(self):
        return hash(self.user_id)

Они также сделали user_id свойством только для чтения, чтобы обеспечить неизменность. Это сохранило возможность использования экземпляров User в качестве ключей, одновременно поддерживая правильную семантику равенства. Результатом стал надежный кэш, который правильно идентифицировал пользователей независимо от идентичности экземпляра объекта.

Что часто упускают кандидаты

Почему Python автоматически устанавливает __hash__ в None, когда __eq__ определен, но __hash__ не реализован?

Когда класс определяет __eq__, базовый по умолчанию хэш, основанный на идентичности, унаследованный от object, становится логически недействительным. Существует по умолчанию __hash__, который зависит от id(self), то есть два различных объекта имеют разные хэши. Если __eq__ переопределено для сравнения значений, два различных экземпляра могут быть равны, но иметь разные хэши, нарушая основное правило, что a == b подразумевает hash(a) == hash(b). Python предотвращает это несоответствие, устанавливая __hash__ в None, явно помечая класс как не хэшируемый, тем самым не позволяя опасному поведению по умолчанию, которое могло бы вызвать непредсказуемую производительность словаря или недоступные ключи.

Что произойдет, если изменяемый объект будет использоваться в качестве ключа словаря после реализации __hash__, основанного на изменяемых полях?

Если __hash__ зависит от изменяемого состояния, значение хэша может измениться после вставки объекта в dict. Словари хранят ключи в хэш-ведрах на основе хэш-значения на момент вставки. Если хэш позже изменяется из-за мутации, последующие запросы вычисляют другой хэш и ищут в другом ведре, что делает оригинальный ключ недоступным. Объект остается в памяти, но не может быть найден или удален через обычный доступ по ключу. Это создает утечку памяти и логическую несоответствие, именно поэтому Python требует, чтобы хэшируемые объекты были неизменяемыми или основанными на неизменяемых идентификаторах.

Как декоратор @dataclass обрабатывает генерацию __eq__ и __hash__, и какой риск связанный с использованием unsafe_hash=True?

По умолчанию @dataclass генерирует __eq__ на основе значений полей, но устанавливает __hash__ в None, делая экземпляры не хэшируемыми. Этот осторожный подход по умолчанию предотвращает ошибки с изменяемыми dataclass. Чтобы разрешить хэширование, вы должны либо установить frozen=True (что делает поля доступными только для чтения и генерирует безопасный __hash__), либо явно установить unsafe_hash=True. Параметр unsafe_hash=True заставляет Python генерировать __hash__ на основе значений полей, даже если поля изменяемые. Это опасно, поскольку, если любое поле изменится после того, как объект использовался в качестве ключа в словаре, хэш изменится, и ключ станет недоступным, что приведет к проблеме "потерянного ключа", описанной ранее. Кандидаты часто упускают, что unsafe_hash — это не просто предупреждение, а функциональный риск, который нарушает инварианты словаря.