初期の Python バージョン（2.2以前）では、メソッドは関数とは異なる型のオブジェクトとして扱われ、バインドされた状態とバインドされていない状態を処理するために明示的な型チェックが必要でした。新しいスタイルのクラスと Python 2.2における型/クラスモデルの統一により、メソッド型は関数の別個のエンティティとして廃止され、バインディングの責任がデスクリプタプロトコルに移行しました。この進化により、関数自体が __get__ を実装できるようになり、インスタンスを通じてアクセスされたときのみ動的にバウンドメソッドが作成され、言語のオブジェクトモデルが簡素化され、内部の型の複雑さが減少しました。
ユーザーがクラス内でメソッドを定義すると、クラス辞書に格納される基盤となるオブジェクトは self を最初の引数として期待するプレーン関数です。問題は、この属性がインスタンスを介して取得される際（例： obj.method）、Python が手動で部分適用やラッパーコードを必要とせずに、そのインスタンスを最初の位置引数として自動的に提供する呼び出し可能なオブジェクトを透過的に構築することを保証することです。これが各属性アクセスで効率的に行われる必要があり、明示的な自己渡しや継承の検査のためにクラスを介してバインドされていない関数（例： Class.method）にアクセスできる能力を維持する必要があります。
関数はその __get__ メソッドを介してデスクリプタプロトコルを実装します。クラス（None のインスタンス）でアクセスされると、 __get__ は関数オブジェクト自体を返します。インスタンスでアクセスされると、 __get__(self, instance, owner) は関数とインスタンスの両方をカプセル化した method オブジェクトを返します。呼び出し時に、このバウンドメソッドは引数タプルにインスタンスを追加してから基盤となる関数を呼び出します。
class Demo: def compute(self, value): return value * 2 d = Demo() # クラスアクセスは生の関数を返します unbound = Demo.__dict__['compute'] print(type(unbound)) # <class 'function'> # インスタンスアクセスは __get__ をトリガーし、バウンドメソッドを返します bound = unbound.__get__(d, Demo) print(type(bound)) # <class 'method'> print(bound(5)) # 10, d.compute(5) と同じ
高頻度取引システムを開発するには、ストラテジーオブジェクトが市場データフィードに価格更新ハンドラを登録する必要があります。最初、開発者は strategy.on_price_update をコールバック参照として渡しました。負荷テスト中に、削除されたストラテジーがガーベジコレクションされないことがメモリプロファイリングによって明らかになりました。なぜなら、フィードがバウンドメソッドの参照を保持していたため、アプリケーションのライフタイムにわたって偶発的な強参照サイクルが作成されていたからです。
一つのアプローチは、ストラテジーとバインドされていない関数を別々に弱い参照として保存し、呼び出し時間に手動で結合することでした。これにより円環参照を防止し、放棄されたストラテジーの即時ガーベジコレクションを可能にします。しかし、これは複雑なコールバック呼び出しロジックを導入し、オブジェクトが生存チェックと呼び出しの間に収集された場合には潜在的な競合状態を引き起こし、Python の直感的なメソッド渡しのイディオムを壊します。
別の選択肢は、 on_price_update を @staticmethod に変換し、登録時にストラテジーインスタンスを明示的に渡すことでした。これにより、バウンドメソッドの作成を完全に回避することにより、参照管理が簡素化されます。しかし、これはオブジェクト指向のカプセル化原則に違反し、関数とインスタンスを別々に受け入れるように登録APIに変更を強要し、ストラテジーとそのハンドラの関係をあいまいにする、可読性の低いコードが生成されます。
我々は、強い参照の代わりにインスタンスへの弱い参照を保持するバウンドメソッドのようなオブジェクトを返すカスタムデスクリプタを実装することを検討しました。これにより obj.method 呼び出し構文が維持され、呼び出し側の視点からメモリリークを防ぎます。欠点は、正しく実装するためにデスクリプタプロトコルに関する深い知識が必要であることと、各呼び出し時に参照の生存確認を行うわずかなオーバーヘッドです。
我々は、WeakMethod デスクリプタを実装するソリューション3を選択しました。これにより、標準の関数バインディングを模倣しながら、インスタンスに対して weakref.ref を使用しました。これにより、市場データフィードはストラテジーのガーベジコレクションを妨げずにコールバックを保持できることができました。このアプローチは、クリーンな登録コードを維持しました：feed.register(ticker, strategy.on_price_update)。
この最適化により、長時間実行される取引セッションでのメモリリークが排除され、数百万の一時的なストラテジーインスタンスへのバックテスト中にメモリフットプリントが40%減少しました。システムは、ユーザーが参照管理の複雑性を理解することなく、クリーンなオブジェクト指向API設計を維持しました。最終的に、バウンドメソッド作成メカニズムの理解が、プロダクショングレードの金融ソフトウェアの構築に不可欠であることがわかりました。
なぜバウンドメソッドを長生きするコンテナに保存すると、元の参照がすべて消えた後でも関連するインスタンスのガーベジコレクションが妨げられるのですか？
バウンドメソッドオブジェクトは、インスタンスへの強い参照を保持する内部 __self__ 属性を持っています。グローバルレジストリーやキャッシュに保存された場合、そのメソッドはインスタンスを無限にアクセス可能にします。これを避けるために、開発者は weakref.WeakMethod を使用するか、別々の弱いインスタンス参照を持つバインドされていない関数を保存しなければなりません。
ポリモーフィックファクトリーメソッドを有効にするために、 @classmethod デスクリプタの __get__ 実装は標準関数とはどのように異なりますか？
classmethod はデータテレストリプタでないものであり、最初の引数にインスタンスの代わりに owner クラスをバインドします。サブクラスでアクセスされると、それはそのサブクラスを cls として受け取り、正しい派生型をインスタンス化する代替コンストラクターを可能にします。これは、静的メソッドとは対照的であり、静的メソッドは自動バインディングを受け取らず、明示的な検査なしに呼び出し元のクラスを特定できません。
インスタンスメソッドに対する繰り返しアクセスの際に CPython レベルで発生するオーバーヘッドは何であり、なぜメソッドキャッシングがパフォーマンスを向上させるのですか？
各アクセス obj.method はデスクリプタプロトコルをトリガーし、関数とインスタンスへのポインタを含む新しい PyMethodObject をヒープ上に割り当てます。この繰り返しの割り当てと解放は、高頻度のループ内でかなりのオーバーヘッドを生み出します。バウンドメソッドをループの外でキャッシュすることで、同じオブジェクトを再利用し、デスクリプタのルックアップコストを排除し、マイクロベンチマークで20-30%の実行時間を短縮します。