Pythonクラスが__eq__を定義して等価性比較をカスタマイズすると、インタープリターは明示的にオーバーライドされない限り、__hash__をNoneに自動的に設定します。これにより、インスタンスはハッシュできなくなり、dictキーやsetメンバーとしての使用が制限されます。基本的な不変条件には、__eq__で等しいと比較されるオブジェクトは同一のハッシュ値を持たなければならないというものがあり、これを違反するとハッシュベースのコレクションで不定な動作が引き起こされます。したがって、そのようなオブジェクトをマッピングキーとして使用しようとすると、TypeError: unhashable typeが発生します。
ある開発チームが、Userオブジェクトがアクティブなセッションを格納するためのメモリ内キャッシュdictのキーとして機能するセッション管理サービスを構築していました。Userクラスは、user_idに基づいてインスタンスを比較するために__eq__を実装しており、同じデータベースユーザーを表す2つの異なるオブジェクトが等しいとみなされるようになっていました。最初の実装は次のようになっていました：
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'**を発生させ、サービスがクラッシュしました。
チームは3つの解決策を考えました。最初のアプローチは、ハッシュ値としてid(self)を使用することでした。これは、user_idが同じであっても異なるハッシュを持つ2つの異なるUserインスタンスが存在し、重要な不変条件に違反するため却下されました。これにより、キャッシュのルックアップが完全に破綻し、同じ論理ユーザーの重複エントリが許されることになりました。
2つ目のアプローチは、ハッシュ値としてhash(self.user_id)を使用することでした。これにより、不変のuser_idを持つ等しいユーザーが同じハッシュを共有するため、不変条件を満たすことができました。ただし、user_idが可変である場合、挿入後にIDが変更されるとオブジェクトは辞書の中で「失われて」しまう可能性があります。
3つ目のオプションは、キーとしてUserオブジェクトの使用を放棄し、代わりに文字列user_idを直接使用することでした。これは安全でシンプルでしたが、型安全性が犠牲になり、IDからUserオブジェクトへの別のマッピングを維持する必要があり、コードベースが追加のルックアップロジックで複雑になりました。
チームは2つ目の解決策を選択し、クラスに次の実装を追加しました：
def __hash__(self): return hash(self.user_id)
また、user_idを読み取り専用プロパティにして不変性を確保しました。これにより、Userインスタンスをキーとして使用できる能力が保持され、正しい等価性セマンティクスを維持しました。その結果、オブジェクトのインスタンスIDに関係なくユーザーを正しく識別する堅牢なキャッシュが実現されました。
なぜPythonは__eq__が定義されているが__hash__が実装されていない場合、__hash__をNoneに自動的に設定するのか？
クラスが__eq__を定義すると、オブジェクトから継承されるデフォルトのアイデンティティベースのハッシュは論理的に無効になります。デフォルトの__hash__はid(self)に依存しており、つまり2つの異なるオブジェクトは異なるハッシュを持ちます。__eq__が値を比較するためにオーバーライドされている場合、2つの異なるインスタンスが等しくても異なるハッシュを持つ可能性があり、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パラメータは、フィールドが可変であってもフィールド値に基づいて__hash__を生成するようにPythonに強制します。これは危険です。なぜなら、オブジェクトが辞書のキーとして使用された後にフィールドのいずれかが変更されると、ハッシュが変わり、キーが見えなくなり、「失われたキー」問題が発生するからです。候補者はしばしばunsafe_hashが単なる警告ではなく、辞書の不変条件を破る機能的リスクであることを見落とします。