Pythonのfunctools.singledispatchは、PEP 443で導入され、Python 3.4でリリースされ、言語にジェネリック関数の機能をもたらします。ClojureやJuliaの類似の機能に触発され、最初の引数の型に基づいて異なる動作をする単一の関数名を書くことを開発者に許可します。これは、isinstance()のチェーンや手動のディスパッチテーブルを使用するという長年のパターンに対処します。これらはコードを混乱させ、オープン/クローズ原則に違反します。
標準化されたディスパッチメカニズムがないため、開発者は関数内で異なるデータ型を処理するためのアドホックな型チェックを実装する必要があります。これにより、新しい型のサポートを追加する際に元の関数のソースコードを修正せざるを得ず、拡張性が損なわれるような、密に結合されたコードが生じます。さらに、仮想サブクラスおよび抽象基底クラスは、最適な一致する実装を決定するためにランタイムのMRO（メソッド解決順序）トラバーサルを必要とするため、静的なディスパッチテーブルに対して課題をもたらします。
実装は、型オブジェクトを対応するハンドラ関数にマッピングする内部の_registry辞書を使用します。汎用関数が呼び出されると、最初の引数の型を抽出し、ルックアップを実行します。正確な型が見つからない場合、型のMROをトラバースして、登録された最も近い親クラスを見つけます。register()メソッドはデコレータファクトリーとして機能し、このレジストリを構築します。仮想サブクラス（抽象基底クラスにregister()で登録されたもの）の場合、ディスパッチャは具体的な型が一致しない場合には、登録された抽象型に対してisinstance()をチェックし、継承なしでポリモーフィックなディスパッチを可能にします。
from functools import singledispatch from abc import ABC class Shape(ABC): pass class Circle(Shape): def __init__(self, radius): self.radius = radius @singledispatch def area(obj): raise NotImplementedError("Type not supported") @area.register(Circle) def _(obj): return 3.14 * obj.radius ** 2 # 仮想サブクラスのサポート @area.register(Shape) def _(obj): return "Abstract shape area"
複数のソースからファイルを取り込むデータ処理パイプラインを考えてみましょう—JSON、XML、およびCSV—それぞれ異なる解析ロジックが必要ですが、標準化された内部表現を生成します。最初の実装では、parse_data(data, file_type)という単一のモノリシックな関数が使用され、大きなif/elif/elseブロックがisinstanceまたは文字列識別子をチェックしていました。新しいフォーマットが追加されるにつれて、これはメンテナンスが不可能になり、コア関数の修正が必要で、回帰のリスクを生じさせました。
一つの代替ソリューションはVisitorパターンであり、解析アルゴリズムをデータ構造から分離します。これにより、オープン/クローズ原則が強制されますが、訪問者クラスと受け入れメソッドの並行階層を作成する必要があり、単純な型ベースのディスパッチには大きなボイラープレートを導入します。このパターンは、データ構造が複雑なオブジェクトでなく単純な文字列やバイトである場合には、不自然に感じられます。
考慮された別のアプローチは、型識別子をハンドラ関数にマッピングする手動ディスパッチ辞書でした。これにより、登録が実装から切り離されますが、Pythonの型システムとの統合が欠けています。これにより、継承階層や抽象基底クラスを自動的に処理できず、開発者が各コールサイトでMROを歩いて最適なハンドラを手動で解決することを強制され、エラーが発生しやすく、繰り返しであるという問題があります。
チームは、functools.singledispatchを選択しました。これは、型ベースのディスパッチのためのファーストクラスサポートを提供し、自動的にMRO解決を行い、クリーンなデコレータベースの登録構文を持つためです。これにより、サードパーティのライブラリがコアライブラリのコードを変更することなく、新しいフォーマットの解析サポートを拡張できるようになります。その結果、解析モジュールのコード行数が40％削減され、新しいフォーマットハンドラを追加する際のマージコンフリクトが排除されました。各フォーマットは独立した登録ブロック内に存在するからです。
singledispatchは、登録されていない引数の型が渡されたときに、どのように正しい実装を解決し、メソッド解決順序（MRO）はどのような役割を果たしますか？
汎用関数が、レジストリに明示的に存在しない型の引数を受け取ると、ディスパッチャはtype(obj).__mro__を使用して引数のクラス階層を調べます。MROタプルを反復処理し——オブジェクトのクラスとその親を線形順序でリスト化——そのシーケンス内の型に関連付けられた最初の登録関数を返します。これにより、親クラスに対して登録されたハンドラがそのサブクラスのインスタンスを正しく処理し、リスコフの置換原則を維持することが保証されます。MRO全体をトラバースした後に一致するものが見つからなければ、ディスパッチャは通常NotImplementedErrorを発生させる@singledispatchで登録された元の関数にフォールバックします。
既存の関数（デコレータではない）やラムダをsimplifiedispatchで登録することはできますか？タイプを登録解除する構文はどのようなものですか？
はい、既存の関数を関数形式で登録できます：generic_func.register(target_type, existing_function)。これは、他の場所で定義された関数やラムダにディスパッチしたい場合に便利です：process.register(int, lambda x: x * 2)。タイプを登録解除するには、そのタイプにNoneを代入します：process.registry[int] = None。これにより、特定のハンドラが削除され、今後そのタイプのディスパッチがMRO検索やデフォルト実装にフォールバックされます。候補者は、デコレータ構文がドキュメントで強調されているため、これを見逃しがちですが、命令的APIはあまり目立っていません。
クラス内で使用される場合、functools.singledispatchmethodはsingledispatchとどのように異なり、なぜ別の実装が必要ですか？
singledispatchmethodはメソッドに必要です。なぜなら、singledispatchは関数の最初の引数で動作しますが、それはメソッドのselfだからです。もしsingledispatchをメソッドに直接適用すると、インスタンスの型に基づいてディスパッチされ、以降の引数の型に基づいてディスパッチされなくなります。singledispatchmethodはディスパッチロジックをバインディングプロセスから分離するために記述プロトコルを使用します：最初にselfをバインドし、その後に残りの引数への型ディスパッチを適用します。これにより、selfの型が意図したディスパッチターゲットに干渉せず、メソッドが最初の非self引数の型に基づいてオーバーロードできるようになります。これはC++やJavaがメソッドオーバーロードを扱う方法に似ています。