JITは取り込まれたが、承認は得られなかった
Pythonの実験的なJITコンパイラは、2023年後半から2024年前半にかけて開始された作業を基に、オプトイン機能としてCPython 3.13で登場しました。コア開発者のBrandt Bucherは、ランタイムパフォーマンスの向上を意図して、copy-and-patch JITを最初にマージしました。
しかし、JITは正式かつ長期的な承認を得られませんでした。JITは、その place と継続的なメンテナンスへのコミットメントを確立するStandards Track PEPではなく、単に機能を説明するだけのInformational PEPであるPEP 744の下で出荷されました。この手続き上の欠落により、JITの将来は当初から不透明でした。
これはバグが原因の撤回ではなく、コード自体は機能していました。むしろPythonプロジェクトは、恒久的なコミットメントなしに実験的な機能を出荷することを認めており、コアチームに無期限のサポート負担を自動的に課さずにイノベーションを生み出す余地を作っています。JITが削除されるのは、正式な合意が得られなかったためであり、技術的な欠陥によるものではありません。
Python Steering Councilは最終的に、Standards Track PEPを確保するか、さもなければJITを削除するという最後通告を出しました。この動きは、実験的なコードを出荷することと、コミュニティとメンテナーに無期限にリソースを投入するよう納得させることとは別であり、後者のほうがオープンソース開発でははるかに困難な課題であることを浮き彫りにしました。
評議会が求めたのは約束ではなく証拠だった
PythonのSteering Councilは、JITの非公式な導入に納得せず、2026年6月に最後通告を出しました。6か月以内にStandards Track提案を提出して承認を得なければ、実験的なJITコードはmainブランチから削除されるというものです。これは提案ではなく、標準的なガバナンスを回避していた機能に対する厳格な期限でした。
これを受けて、Savannah Savannah Ostrowski、Ken Jin、Brandt Bucherは、2026年7月に、「JIT Go Brrr: The Path to a Supported JIT Compiler for CPython」と題したPEP 836を提出しました。評議会による10項目の批評は迅速かつ容赦のないものでした。セキュリティへの配慮が不十分であるとして、これを「対応が不十分な領域」と呼んで厳しく批判し、パフォーマンスとユーザーへの影響に関する予測を「楽観的すぎる」と退けました。
おそらく最も痛烈な指摘は、2028年8月のPython 3.17リリース候補で予定されていた互換性レビューの提案に関するものでした。評議会はこのスケジュールを「あまりにも遅すぎる」と判断し、即時かつ確固たる保証を求める姿勢を強調しました。説得力のあるロードマップがないまま、当初の期待にもかかわらず、JITの将来はますます厳しいものに見えました。
有望な提案は、担い手を失った
Python Steering Councilの最後通告が重くのしかかる中、有望な提案は足場を固めることができませんでした。2026年10月19日、Python 3.16および3.17のリリースマネージャーであるSavannah Savannah Ostrowskiは、JITをStandards Trackの地位に引き上げることを目的とした「JIT Go Brrr」提案であるPEP 836を正式に取り下げました。その理由として挙げられたのは、「現行バージョンを前に進めるための個人的な余力」が著しく不足していることでした。
これはJITに価値がないという宣言ではなく、むしろその逆でした。Savannah Ostrowskiとそのチームは、PythonのパフォーマンスをJITが向上させる可能性があると引き続き確信していました。取り下げの背景には、セキュリティ上の懸念への対応や、限定的なベンチマークで観測された幾何平均4~12%の高速化よりも確かなパフォーマンス向上の実証など、評議会の厳しい要求を満たすために必要なエンジニアリング面と政治面の多大な労力がありました。
評議会のフィードバックは率直で、セキュリティを「対応が不十分な領域」と呼び、Python 3.17向けに提案された2028年8月の互換性レビューは「あまりにも遅すぎる」と評しました。これらの点に包括的に取り組むための専任リソースがなく、PEP 836は先に進めませんでした。JITが当初、より非公式な形で導入された経緯については、PEP 744 – JIT Compilationを参照してください。
その結果、実験的なJITのコードはPython 3.16の開発サイクルの初期にCPythonのmainブランチから削除されることがほぼ確実となりました。ツリー内JITをめぐるPythonの短い試みは終わったようであり、コードを出荷することが最も容易な部分であることが多いというオープンソースの現実の犠牲になった形です。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
真のボトルネックは長期的なオーナーシップ
コードをマージすることは、オープンソース開発の終わりではなく始まりです。CPythonのmainブランチからJITが削除されようとしていることは、重要な教訓を示しています。オーナーシップは最初のコミットにとどまらないということです。メンテナーは、セキュリティレビュー、互換性のリスク、メモリコスト、長期サポートに対して継続的な責任を負います。JITチームは、この技術を信じていたものの、その負担を維持することができませんでした。
この結果を、Pythonのパフォーマンス向上の取り組みが止まることだと誤解すべきではありません。JITは実験的でオプトイン方式の機能でした。Python 3.11および3.12での大幅な改善を含め、CPythonの最近の高速化の多くは、別個の、現在も継続中の最適化戦略であるspecializing adaptive interpreterによるものです。
さらに、この決定はPythonのJIT開発全体の終わりを意味するものではありません。PyPy、Numba、PyTorch Inductorといった代替プロジェクトは、引き続きJITコンパイルを活用しています。これらのソリューションは異なるワークロードや実行環境に対応しており、CPythonのコア開発の枠外で運用されています。このことは、特定の高性能Pythonアプリケーションにとって、JITという概念が依然として重要であることを示しています。
よくある質問
CPythonはなぜ実験的なJITを削除するのですか?
JITは承認済みのStandards Track PEPを持たず、セキュリティと互換性に関する未解決の懸念があり、さらにメンテナーが提案を前に進めるために必要な工数を確保できませんでした。
JITはバグがあったために削除されたのですか?
いいえ。決定の中心となったのは、ガバナンス、長期的なメンテナンス、セキュリティレビュー、そして期待される利点がコストに見合うかどうかでした。
PEP 744とPEP 836の違いは何でしたか?
PEP 744は実験的なJITを文書化したもので、情報提供(Informational)の位置づけでした。PEP 836はサポート対象のJITの正式な承認を求めるものでしたが、筆頭著者によって取り下げられました。
これはPythonにJITが搭載されることは決してないという意味ですか?
いいえ。今回の決定はCPythonのmainブランチにあるJITに関するものであり、独立したプロジェクトや今後の提案によって、JITコンパイルを追求することは引き続き可能です。