質問の履歴
Pythonのデータモデルでは、属性アクセスは厳格なプロトコルに従い、__getattribute__は基本のobjectクラスで定義されており、すべての属性ルックアップのための主要なインターセプターとして機能します。このメソッドは、存在するかどうかに関係なく、すべての属性アクセスに無条件で呼び出されるため、解決チェーンの最初の防御線となります。一方、__getattr__はオプショナルなフックであり、通常のインスタンス辞書およびクラス階層を通じた検索で要求された名前が見つからなかったときのみインタプリタによって呼び出されます。
問題
サブクラスが__getattribute__をオーバーライドしてログ記録やアクセス制御などの動作をカスタマイズする場合、メソッド本体内での直接的な属性アクセス（例えば、self.attrやself.__dict__）は、同じオーバーライドされたメソッドを再帰的にトリガーします。これは、ルックアップメカニズムが基本ケースなしでハイジャックされ、無限ループを引き起こし、最終的にはコールスタックを枯渇させてRecursionErrorを発生させます。
解決策
__getattribute__を安全に実装するには、super().__getattribute__(name)またはobject.__getattribute__(self, name)を使用して基本実装にデリゲートする必要があります。これにより、オーバーライドされたロジックをバイパスし、カスタムメソッドに再度入ることなくインスタンス辞書またはクラス階層からの実際の属性取得が行えます。このパターンは、オブジェクトモデルの整合性を保ちながら、無限ループを防ぎ、結果をラップ、検証、変換できるようにします。
コード例
class SafeProxy: def __init__(self, wrapped): # 初期化中の再帰を避けるためにここでsuper()を使用する必要があります super().__setattr__('_wrapped', wrapped) def __getattribute__(self, name): # 取得前にアクセスをログ出力 print(f"アクセス中: {name}") # 無限再帰を避けるためにオブジェクトにデリゲート return super().__getattribute__(name)
シナリオ
開発チームは、すべてのフィールドアクセスをログに記録する必要があるレガシーORMモデルの監査トレイルを実装する必要がありますが、元のモデルクラスを変更することはできません。彼らは、数百のモジュールにわたる既存のビジネスロジックを壊さずに透明性を持って読み取りをインターセプトするソリューションを必要としています。
問題の説明
システムは、タイムスタンプとユーザーアクションを記録するために、既存の属性と存在しない属性の両方をインターセプトする必要があります。動的フィールドの数が多いため、個々のメソッドにログを追加するための単純なサブクラス化は実行不可能です。ソリューションは既存のコードに透明でなければならず、モデルのパブリックインターフェースを変更することはできません。
ソリューション1: モデルメソッドのモンキーパッチ
このアプローチは、ログ呼出しを注入するためにクラスのメソッドをランタイムで動的に置き換えることを含み、ソース定義を変更せずに特定の動作をターゲットにします。設定に基づいて条件付きで適用を可能にし、継承の複雑さを避けることができます。ただし、データディスクリプタや単純な値への直接的な属性アクセスをインターセプトできず、新しいメソッドごとにメンテナンスが必要であり、内部実装の詳細が変更された場合には破損します。
ソリューション2: ログのための__getattr__の使用
存在しない属性へのアクセスをログに記録するために__getattr__を実装することは、単純なフォールバックメカニズムを提供します。再帰の問題から安全であり、最小限のボイラープレートで実装が容易です。残念ながら、インスタンスやクラスに存在しない属性に対してのみトリガーされるため、既存のフィールドへのアクセスの大部分を逃してしまい、包括的なロギングの監査要件を満たせません。
ソリューション3: __getattribute__を持つプロキシクラス
__getattribute__を実装したラッパークラスを作成することで、ラップされたORMインスタンスにデリゲートする前にすべての属性の読み取りをインターセプトし、すべてのアクセスを均一にキャッチします。これにより、コンポジションを通じて透明性が維持され、レガシーコードに触れることなく前処理と後処理が可能になります。トレードオフは、慎重な再帰処理の要件と、すべての属性アクセスでの追加メソッド呼び出しによるわずかなパフォーマンスオーバーヘッドです。
選ばれたソリューション
チームは、コンプライアンス規制により、メソッドが触れない単純なデータフィールドを含むすべての属性読み取りをキャッチする必要があったため、__getattribute__を伴うプロキシアプローチを選択しました。プロキシパターンは、カプセル化を維持しながら完全なインターセプション機能を提供し、レガシーORMをきれいに保ち、監査層を意識させません。この選択は、全面的なカバレッジと監査の整合性のために最小限のパフォーマンスを犠牲にしました。
結果
この実装は、レガシーコードベースに対する単一の再帰エラーや変更を伴わずに、1時間あたり50,000件以上の属性アクセスを本番環境で正常にログ記録しました。super()を使用したデリゲーションパターンにより、安定した動作が保証され、テスト環境ではラッパーのインスタンス化を単に削除することでプロキシを無効にすることができ、このアプローチの柔軟性を示しました。
なぜ__getattribute__内でself.__dict__にアクセスすると無限再帰が発生するのか？
オーバーライドされた__getattribute__メソッド内でself.__dict__を書くと、Pythonはインスタンス内の__dict__という名前の属性をルックアップしなければなりません。このルックアップは、カスタム__getattribute__メソッドを再度呼び出し、再びself.__dict__にアクセスしようとし無限サイクルを引き起こします。このループを解決するには、object.__getattribute__(self, '__dict__')を使用する必要があり、これはオーバーライドをバイパスし、基本オブジェクト実装から直接辞書を取得します。
__getattribute__は__getattr__よりもディスクリプタプロトコルにどのように影響を及ぼすのか？
__getattribute__は属性解決チェーンの最初に位置し、ディスクリプタプロトコルが__get__メソッドをチェックする前にルックアップをインターセプトします。あなたの実装がsuper()にデリゲートせずに値を返す場合、propertyやカスタムデータディスクリプタのようなディスクリプタは完全にバイパスされます。一方、__getattr__は、ディスクリプタプロトコルとインスタンス辞書の両方のルックアップが失敗した後にのみ実行されるため、クラス階層に存在するディスクリプタを決してインターセプトしません。
__getattribute__内で手動でAttributeErrorを発生させることの結果は何か？
標準の属性アクセスでは、AttributeErrorが発生すると、フォールバックとして__getattr__がトリガーされる可能性がありますが、Pythonは__getattribute__を権威あるソースとして扱います。カスタム実装がAttributeErrorを発生させると、インタプリタは__getattr__を呼び出そうとすることなく例外を即座に伝播させます。したがって、プライマリフックが失敗した場合に__getattr__に依存することはできず、__getattribute__内で欠落キーを処理するか、正しく例外を発生させる親実装にデリゲートする必要があります。