【ITニュース解説】Understanding Late Binding in Python Closures

Pythonにおいて、関数は単なる一連の命令の羅列ではない。関数が別の関数の内部で定義される場合、それは「クロージャ」と呼ばれる特別な存在になる。クロージャは、それが定義された親の環境、具体的には親関数内で定義された変数などを記憶する小さなコード片である。しかし、この「記憶」は過去の特定の瞬間のスナップショットではない。それは、クロージャが実行されるその時まで、参照している変数の現在の値を常に反映するような性質を持つ。この性質こそが「遅延バインディング」と呼ばれる現象の本質である。

最も単純なクロージャの例を見てみよう。ある関数 make_commission の内部で execute_commission というクロージャが定義される場合がある。この execute_commission は、親関数である make_commission 内で定義された item という変数を記憶している。もし make_commission が「sun」という item を受け取り、それを使って execute_commission を生成し、すぐに実行するならば、期待通りに「sun」と出力される。この場合、クロージャは自身の明確な目的を単一の形で記憶しているため、特に問題は発生しない。

しかし、この遅延バインディングの特性が問題となるのは、複数のクロージャがループの中で同時に作成され、それらが同じ変数を共有している場合である。例えば、make_commissions という関数が、「sun」「moon」「cloud」といった複数の指示を受け取り、それぞれの指示に対応するクロージャをリストとして返すケースを考える。コードは for instruction in instructions: ループの中で、各 instruction に基づいてクロージャを作成し、リストに追加していく形になる。この場合、多くの人は出力が「sun」「moon」「cloud」となることを期待するだろう。しかし、実際にこのコードを実行すると、出力は「cloud」が3回繰り返される結果となる。

これが遅延バインディングの核心である。ループ内で作成された execute_commission 関数は、作成された瞬間の instruction の「値」をキャプチャ（取得・保持）するわけではない。そうではなく、instruction という「変数そのものへの参照」を保持しているのだ。つまり、クロージャが実行されるその時まで、instruction がどんな値を持っているかはわからない状態である。for ループがすべて完了し、リスト内のクロージャがようやく実行される時点では、instruction 変数はすでに最後の値である「cloud」に更新されている。結果として、リスト内のすべてのクロージャが同じ instruction 変数を参照しているため、それらが実行される際には全て「cloud」という最終値を使って動作してしまうのである。

この望ましくない挙動を修正するためには、各クロージャが作成される時点で、instruction のその時の「値」を個別にキャプチャする方法が必要になる。クロージャに、それぞれのコマンドを独立して記憶させる工夫が必要だ。

一つの効果的な解決策は、関数の「デフォルト引数」を利用することである。Pythonでは、関数のデフォルト引数は、その関数が定義される際に一度だけ評価されるという特性がある。この特性を活かして make_commissions 関数を修正できる。具体的には、クロージャとなる execute_commission 関数を定義する際に、def execute_commission(item=instruction): のようにデフォルト引数として instruction を渡すのである。こうすることで、ループが回るたびに execute_commission が新しく定義されるたび、その時点の instruction の値が item パラメータにバインドされる。その結果、各クロージャは instruction の固有のコピーを保持するようになり、同じ単一の変数参照を共有するのではなく、それぞれが異なる値を持つようになる。これで、出力は期待通り「sun」「moon」「cloud」となる。

この遅延バインディングの原則は、lambda 関数、つまり名前を持たない匿名関数にも適用される。lambda 関数もループ内で作成されると、前述の「遅延バインディング」の効果が頻繁に発生する。元の問題と同様に lambda: instruction のように lambda を書くと、これも instruction 変数そのものを参照するため、結果は「cloud」が3回となる。これを修正するには、lambda item=instruction: item のように lambda 関数にデフォルト引数を与えることで、instruction の値を個別にキャプチャできる。さらに、この手法はリスト内包表記と組み合わせることで、より簡潔かつPythonらしいコードとして記述することが可能だ。

もしデフォルト引数を使えない状況があった場合、他の方法で各クロージャが instruction をすぐにキャプチャするように強制することはできるのだろうか。その解決策の一つは、各 instruction に対して新しいスコープを作成することである。これにより、各クロージャが固有の「声」に耳を傾けるようにする。

これは「ファクトリ関数」を導入することで実現できる。ファクトリ関数とは、他の関数を生成して返す関数のことである。create_executor というファクトリ関数を定義し、それに instruction を引数として渡す。ループの各イテレーションで create_executor(instruction) を呼び出すと、その関数は現在の instruction の値を受け取る。そして、その create_executor の内部で execute_commission クロージャが作成され、create_executor のローカル変数である item を参照するようになる。Pythonの変数探索ルール（LEGBルール）に基づき、item は create_executor のローカル変数であるため、外側のループの instruction 変数の変更から隔離される。create_executor が呼び出されるたびに、それが返すクロージャのために新しい、プライベートなメモリが作成されるようなイメージだ。

その他にも、同じ結果を得るためのより簡潔な方法や、関数型プログラミング的なアプローチも存在する。例えば、Python標準ライブラリの functools.partial を利用する方法がある。これは、特定の関数に対して引数を「部分的に適用」することで、その引数が固定された新しい関数オブジェクトを作成する機能である。functools.partial(関数名, 引数) のように記述することで、関数と引数を事前にバインドし、新しい関数として扱うことができる。これも、各クロージャに特定の instruction を個別に記憶させる効果的な手段となる。

最終的に理解すべきことは、クロージャが作成される際に、それが参照する変数の「値」ではなく「参照」を記憶するというPythonの特性である。このため、クロージャが実際に実行される時点での、参照している変数の最終値が使われることになる。この遅延バインディングの挙動を正しく理解し、必要に応じてデフォルト引数、ファクトリ関数、functools.partial などの手法を用いて、クロージャが期待通りの値をキャプチャできるようにコードを記述することが、堅牢なプログラムを作成する上で不可欠である。