__prepare__メソッドは、Python 3.0でPEP 3115を介して導入され、クラス作成プロトコルの基本的な制限に対処します。この変更以前は、クラス本体の実行中に使用される名前空間は常に標準辞書であり、属性宣言の順序を保持したり、発生したアサインメントをインターセプトする方法がありませんでした。これは、属性宣言のシーケンスを追跡する必要のあるORMやシリアル化ライブラリを構築する開発者にとって特に問題となりました。
Pythonがクラス本体を実行すると、最終的にクラスの__dict__になる名前空間マッピングが生成されます。デフォルトのdict型は、古いPythonのバージョンでは挿入順序を保証せず、名前が定義される瞬間に検証または変換するためのフックがありません。特定の命名パターンを禁止したり、バイナリプロトコルのフィールド順序を追跡したりする必要のある開発者は、クラスオブジェクトが確定される前にこの特定のクラス構築の段階にフックするためのクリーンなメカニズムがありませんでした。
メタクラス内の静的メソッドとして__prepare__を実装することで、カスタムのミュータブルマッピング（collections.OrderedDictやカスタム検証辞書など）を名前空間とすることができます。このマッピングは、ボディ実行中のクラスレベルのすべてのアサインメントをキャプチャし、メタクラスの__new__メソッドがクラスを最終化する前に前処理を行うことを可能にします。カスタム名前空間はその後__new__に渡され、標準のdictに変換されるか、順序付きアクセスのために保持されます。
from collections import OrderedDict class OrderPreservingMeta(type): @staticmethod def __prepare__(name, bases, **kwargs): return OrderedDict() def __new__(mcs, name, bases, namespace, **kwargs): ordered_attrs = list(namespace.keys()) cls = super().__new__(mcs, name, bases, dict(namespace)) cls._declaration_order = ordered_attrs return cls class Schema(metaclass=OrderPreservingMeta): id = 1 name = "test" value = 3.14 print(Schema._declaration_order) # ['id', 'name', 'value']
ある金融トレーディングプラットフォームは、プロトコルヘッダー内のフィールド順序がPythonのメッセージクラス定義内の宣言順序に厳密に一致するバイナリメッセージフォーマットを生成する必要がありました。フィールドの順序を変更すると、取引拒否やシステムクラッシュを引き起こす可能性があるため、古い**C++**パーサーとの互換性が壊れてしまいます。
解決策A: 手動インデクシング。 開発者は、各フィールドにfield_order = 1のようなシーケンス番号を注釈することになります。このアプローチは明示的であり、初心者にも理解しやすいです。しかし、DRY原則に違反し、リファクタリング中にはメンテナンスの負担になります。
解決策B: ソースコードのパース。 フレームワークは、ASTモジュールを使用してクラス定義ソースをパースし、アサインメント順序を抽出できます。これはメタクラスの複雑さなしで機能しますが、ランタイムにソースファイルが利用できない場合、例えばフローズンバイナリ配布や最適化されたCPythonデプロイメントでは完全に機能しません。
解決策C: __prepare__を持つメタクラス。 __prepare__からOrderedDictを返すことで、メタクラスは自然な宣言順を自動的にキャプチャします。これはすべてのデプロイシナリオで堅牢であり、エンドユーザーに対して透明です。唯一の欠点は、Pythonのメタクラスプロトコルを理解する追加の複雑さです。
選ばれた解決策: チームは解決策Cを選択しました。これは、メッセージインスタンスごとのランタイムオーバーヘッドなしで、定義時に保証を提供します。
結果: メッセージライブラリはワイヤフォーマットの互換性を自動的に維持しました。開発者は自然なクラス定義を記述し、システムは正しいバイナリレイアウトを生成しました。継承階層は親フィールド順序を子フィールドの前に正しく保持し、手動介入なしで取引プロトコル仕様における複雑な問題を解決しました。
質問1: なぜ__prepare__は@staticmethod（または@classmethod）として定義されなければならないのか、通常のインスタンスメソッドを省略するとどのようなエラーが発生しますか？
回答: __prepare__はメタクラスインスタンスが作成される前に呼び出されるため、まだバインドされるclsやselfがありません。Pythonは名前空間を生成するために__prepare__を呼び出します。もしこれがselfを期待する通常のインスタンスメソッドで定義されていると、Pythonは位置引数を取るが何も渡されていないというTypeErrorを発生させます。暗黙の最初の引数バインディングなしで呼び出される必要があるため、静的メソッドでなければなりませんが、メタクラス自体へのアクセスが必要な場合はclassmethodを使用することもできます。
質問2: __prepare__はdictのサブクラスではないマッピングを返すことができますか？それがクラス本体実行中に正しく機能するために満たすべき特定のプロトコルは何ですか？
回答: はい、MutableMapping抽象基本クラスプロトコルを実装する任意のミュータブルマッピングを返すことができます。特に__setitem__、__getitem__、__contains__、理想的には__iter__またはkeys()を実装する必要があります。ただし、そのマッピングはdictから継承する必要はありません。重要な要件は、文字列キーと任意の値を受け入れ、クラス本体内で属性アサインメントの際に辞書のように振る舞う必要があることです。クラス実行後、メタクラスの__new__はこのマッピングを受け取ります。もしそれがdictのサブクラスでない場合、明示的に変換する必要があります（例: dict(namespace)）ので、super().__new__を呼び出す前にそうする必要があります。
質問3: __prepare__はクラス定義ヘッダーに渡されたキーワード引数（例: class MyClass(metaclass=Meta, strict=True)）をどのように処理し、これらが正しく転送されないとどうなりますか？
回答: クラスヘッダーのキーワード引数（metaclassの他）は、__prepare__に**kwdsとして渡されます。__prepare__が**kwargs（または特定の名前付き引数）を受け取れない場合、Pythonはunexpected keyword argumentというTypeErrorを発生させます。これは、メタクラスに設定オプションを追加する際の一般的な落とし穴です。メソッドシグネチャは__prepare__(name, bases, **kwargs)である必要があり、将来の互換性を確保します。これらのキーワードは、その後__new__や__init__に渡され、メタクラスが準備時に名前空間の動作をカスタマイズするための設定を受け取ることができます（例えば、厳密な検証モードと寛容な検証モードの選択など）。