初期の Python バージョンでは、属性の解決はインスタンス辞書を深さ優先で検索し、その後クラス階層を通過する簡素な方法に依存していました。このアプローチは、計算された値が曖昧さなく読み書きを中断する必要がある堅牢なプロパティライクな動作を実装するには不十分でした。Python 2.2 で新しいスタイルのクラスが導入され、優先順位の競合を解決するために __set__ または __delete__ の有無に基づいてディスクリプタを分類するディスクリプタプロトコルが確立されました。
厳密な優先順位ルールがないと、インタープリタはインスタンスのローカルストレージがクラスレベルの定義を上書きすべきかどうかを判断できませんでした。インスタンス辞書が常に優先されている場合、プロパティは割り当てを検証できませんでした。なぜなら、値が直接 __dict__ に保存されてしまうからです。逆に、クラス属性が常に優先される場合、通常のインスタンス変数はメソッドや他のクラス属性と名前が衝突した場合にアクセスできなくなります。
Python の属性参照アルゴリズムは、データディスクリプタ（__set__ または __delete__ を定義するもの）がインスタンス辞書よりも優先され、非データディスクリプタ（__get__ のみを定義するもの）がインスタンス辞書に譲ることを義務付けています。この設計により、@property は書き込みを遮断することにより検証ロジックを強制できる一方で、通常の関数やキャッシュされたプロパティは複雑なメタプログラミングなしでインスタンスごとに上書き可能です。
ある開発チームは、金融取引プラットフォームのための高スループットデータ検証レイヤーを構築していました。彼らは、受信する市場データを規制要件に厳格に照合する永続的なフィールドが必要で、無効な値が割り当てられないようにしていました。また、高頻度取引のバース中にボラティリティインデックスの高コストな再計算を避けるため、インスタンスごとにキャッシュ可能な計算されたメトリクスも必要でした。
考慮されたアプローチの1つは、@property デコレーターを使用してすべての属性をプロパティとして実装することでした。これにより、プロパティのセッターメソッドを介してすべての書き込み操作を遮断することによって包括的な検証制御が可能となりました。しかし、この設計では、信頼できる内部キャッシュからシリアライズされたデータを読み込むときに検証をバイパスできなくなり、大量のリプレイ操作中に不要な計算オーバーヘッドを引き起こしました。
別のオプションは、ベースクラスで __setattr__ をオーバーライドして、バリデーションロジックを単一のメソッドに集約することを含んでいました。この中央集権的な制御はバリデーションルールの単一の変更ポイントを提供しましたが、検証を必要とする永続的なフィールドと一時的な計算キャッシュを区別するための脆弱な分岐ロジックを導入しました。さらに、このアプローチは、サードパーティ製のシリアライズライブラリが期待する標準的な属性アクセスパターンに干渉し、統合の失敗を引き起こしました。
選択された解決策は、中央集権的なオーバーヘッドなしに両方の要件を満たすためにディスクリプタプロトコルの二分法を直接活用しました。チームは ValidatedField をデータディスクリプタとして実装し、__set__ メソッドで型と範囲の制約を強制し、データディスクリプタがインスタンスの状態に関係なく常に割り当てを遮断することを保証しました。計算されたメトリクスについては、__get__ のみを実装する非データディスクリプタとして CachedMetric を作成し、値が計算されてローカルに保存されると、インスタンス辞書がディスクリプタを覆い隠すことができ、以降のアクセス時の再計算をバイパスしました。
このアーキテクチャにより、外部入力に対する厳格な検証が提供される一方で、導出値のための柔軟で効率的なキャッシングが許可されました。システムはキャッシュの水和中に検証ボトルネックなしで高ボリュームの市場フィードを成功裏に処理しました。ベンチマークでは、プロパティのみのアプローチと比較して、歴史的なリプレイシナリオ中の検証オーバーヘッドが40%削減されたことが明らかになり、リアルタイムデータの摂取に対する完全な規制遵守を維持しました。
属性を削除すると、ディスクリプタに __delete__ メソッドがない場合、データディスクリプタをバイパスしますか？
データディスクリプタが __set__ を実装しているが __delete__ を省略している場合、del obj.attr を介して属性を削除しようとすると、インスタンス辞書にフォールバックしません。Python は、__set__ が存在するため、そのオブジェクトをデータディスクリプタとして認識し、削除操作は属性を削除できないことを示す AttributeError を発生させます。削除を許可するには、ディスクリプタがインスタンスから値を削除するために明示的に __delete__ を定義する必要があります。または、クラスがカスタム削除ロジックを実装しなければなりません。削除操作中にデータディスクリプタ属性についてインスタンス辞書を調べるメカニズムはありません。
なぜ super().attribute は現在のクラスで定義されたデータディスクリプタを無視しているように見えるのですか？
super() プロキシは、現在のクラスの次に続くクラスの階層でメソッド解決順序（MRO）の検索を開始する協調的な多重継承メカニズムを実装しています。ディスクリプタが現在のクラス自体で定義されているため、super() は検索中にそれをスキップします。ただし、親クラスが同じ名前のデータディスクリプタを定義している場合、super() はそれを見つけ、標準のデータディスクリプタ優先順位ルールを適用し、インスタンスとオーナークラスを適切に使用して __get__ を呼び出します。この動作は、MRO の開始ポイントに由来し、super プロキシオブジェクトのディスクリプタに対する特別な免除からのものではありません。
__slots__ は、ストレージ制約を強制するためにどのようにディスクリプタプロトコルを利用しますか？
クラスが __slots__ を定義すると、Python インタープリタは各スロット名のために自動的に専門の内部ディスクリプタ（通常は C レベルの member_descriptor オブジェクト）を作成し、クラス辞書に配置します。これらのディスクリプタは __get__ と __set__ の両方を実装しており、従来のインスタンス辞書に値を格納しようとする試みよりも優先されるデータディスクリプタです。スロットクラスのインスタンスは通常、スロットリストに "__dict__" が明示的に含まれない限り __dict__ を欠くため、ディスクリプタプロトコルはスロット属性に対するすべての読み取りと書き込みがこれらの C レベルのディスクリプタを通じて行われることを保証し、任意の属性付加を防ぐことによって型の安全性とメモリ効率を強制します。