Python では、クロージャは値ではなく参照で変数をキャプチャするため、LEGB (ローカル, 包含, グローバル, ビルトイン) ルックアップメカニズムによって定義された言語の字句的スコープルールに従います。ループ内で関数が定義されると、関数はその瞬間に持っていた値ではなく、変数名自体をクロージャします。その結果、ループが完了した後に関数が呼び出されると、包含スコープで変数を見つけ、最終的に割り当てられた値のみを見つけます。この動作はレイトバインディングとして知られており、Python が名前解決を実行時まで遅らせ、デフォルト引数を定義時にのみ評価するために発生します。早期バインディングを強制するために、開発者は lambda x=x: ... または def func(x=x): ... のイディオムを利用します。この場合、デフォルト引数式は即座に評価され、オリジナルのループ変数とは独立して持続するローカルパラメータ内の現在の反復の値をキャプチャします。
配置ファイルに基づいてバックグラウンドワーカーが動的にスケジュールされるFlaskアプリケーションのデータ処理パイプラインを開発していると想像してください。開発者は、特定のパーサーをトリガーするための各ファイルタイプに対するラムダコールバックを作成する登録ループを記述します。たとえば for file_type in ['csv', 'json', 'xml']: callbacks.append(lambda: process(file_type)) のようにします。実行時に、すべてのコールバックが予想外にも XML ファイルのみを処理します。なぜなら、すべてのクロージャが ループの終了後に 'xml' を保持する同じ file_type 変数を参照しているからです。
デフォルト引数を使用する: lambda ft=file_type: process(ft) にリファクタリングすることで、各ラムダが現在の file_type 値をデフォルトパラメータとしてキャプチャすることが保証されます。利点: 最小限のコード変更が必要であり、構文的に簡潔です。欠点: 呼び出し元がこのパターンに不慣れであれば関数シグネチャにパラメータが追加され、混乱を招く可能性があり、キャプチャされた変数が多く必要な場合にはスケールしにくいです。
ファクトリ関数を使用する: def make_handler(ft): return lambda: process(ft) のように専用のビルダーを作成し、make_handler(file_type) を追加することで、各値を自身の包含スコープ内に隔離します。利点: 意図を明示的に示し、シグネチャの汚染を避け、複雑な初期化ロジックをクリーンに処理します。欠点: 単純なケースに対して過剰に見える追加のボイラープレートと間接性が導入されます。
functools.partial を利用する: ラムダを functools.partial(process, file_type) で置き換えると、引数が即座にバインドされ、ループ変数に対するクロージャが作成されません。利点: 機能的プログラミングアプローチであり、明示的でラムダのオーバーヘッドを回避します。欠点: コールバック内での変換には柔軟性が低く、functools のインポートが必要です。
選択した解決策: この単純なコールバックシナリオにおいて、簡潔さのためにデフォルト引数パターンが選択されましたが、今後の複雑なハンドラーのためにファクトリーアプローチが文書化されました。
結果: パイプラインは、CSVファイルをCSVパーサーに、JSONをJSONパーサーに、XMLをXMLパーサーに正しく配信し、各コールバックが独立した状態を維持しました。
なぜ関数を定義するリスト内包表記は、ループを含みながらもこのレイトバインディングの問題に悩まされないのですか？
Python 3のリスト内包表記は独自のローカルスコープで実行され、構築中に即座に式を評価し、実際に作成時に関数に現在の値をバインドします。完了後にループ変数 i が包含名前空間に残るのとは異なり、内包表記のイテレータ変数はローカルスコープであり、各反復で異なっているため、共有参照の問題を防ぎます。さらに、関数が内包表記内で直ちに呼び出される場合（例：[f(i) for i in range(5)]）、値はスタックに直接渡され、クロージャメカニズムを完全に回避します。
def handler(data=[]): のような可変デフォルト引数を使用すると、ループ内で関数を作成する際のクロージャキャプチャにどのように影響しますか？
可変デフォルトは他のデフォルト引数と同様に定義時に評価されますが、可変オブジェクト自体は一度作成され、ループコンテキストの外に def ステートメントがある場合、すべての関数定義で共有されます。ファクトリ関数やラムダで data=data を使用すると、その瞬間に参照が正しくキャプチャされますが、複数のクロージャが同じ可変デフォルトをキャプチャする場合、一つのクロージャでの変更が他のクロージャに予想外の影響を及ぼすことになります。これにより、クロージャが独立しているように見えて、実際には基盤にあるデータ構造を共有してしまう微妙なバグが発生し、交差汚染を防ぐためには不変のデフォルトや内部初期化の明示的な None チェックが必要です。
ループ変数がグローバルスコープではなく包含関数スコープに存在する場合、nonlocal キーワードでこの問題は解決できますか？
いいえ、nonlocal はネストされた関数が最も近い包含スコープのバインディングを修正することを明示的に許可しますが、各反復ごとに新しいバインディングを作成するわけではありません。すべてのクロージャは依然として包含スコープの変数環境における正確に同じセルを参照します。一つのクロージャ内でキャプチャされた変数を nonlocal を使用して修正すると、同じループ内で作成された他のすべてのクロージャで見える値が変更され、潜在的にカスケード副作用や競合条件を引き起こす可能性があります。各クロージャごとに異なる値を得るには、依然としてデフォルト引数やファクトリ関数を使用して各反復のデータ用の個別のストレージ場所を確立する必要があります。