Pythonの実験的なJIT compilerが、CPython本体から外されようとしている。いま取り上げる価値があるのは、単なる機能の追加・削除ではなく、Pythonの“本流”に新しい仕組みを入れるときに、どこまでを実験として許し、どこから先を正式な機能として扱うのかがはっきり見えたからだ。しかも今回は、対立がこじれて消えたというより、手順と責任の置き方を巡って静かに行き詰まった。Pythonコミュニティの進め方そのものが問われた話でもある。
問題のJITは、2024年初めにBrandt BucherがCPythonへ入れた実験機能だ。ちょうどPython 3.13向けの話として進み、当初は大きな機能なので標準化されたPEPを通してから入るべきだったはずなのに、最初はそうなっていなかった。Thomas WoutersがリリースマネージャーとしてPEP作成を促し、BucherとSavannah OstrowskiがPEP 744「JIT Compilation」を書いた。このPEPは informational PEP で、コミュニティに情報を共有するためのものであり、正式に機能採用を決めるものではない。
その後、Python steering councilは2026年6月になって立ち止まった。JITをCPython main branchで続けるには、保守のしかた、互換性、成功の指標、完成までのタイムラインを明示した standards-track PEP が必要だと求めたのだ。期限は6か月。もし受理されなければ、main branchからJITコードを削除する、という条件まで付いた。これを受けてBucher、Ostrowski、Ken JinがPEP 836「JIT Go Brrr: The Path to a Supported JIT Compiler for CPython」をまとめ、7月3日にPython forumへ出した。議論はかなり活発で、内容を二つのPEPに分けるべきだという指摘や、実装詳細を入れすぎだという批判、追加説明を求める声が出た。
9月21日、steering councilは立場をまとめた声明を出す。PEP 836は、求めた質問には一応答えている。ただし、いくつかは説得力が弱い。councilが本当に見たかったのは、JITを「サポート済みの非実験的な機能」にする条件ではなく、あくまで main branch で実験を続けるべきかどうかだった。懸念は広い。メモリへの影響、platform parity、ユーザーへの見え方、security、そして互換性レビューの時期まで含まれていた。たとえば、PEP 836では最初のPython 3.17 release candidate、つまり2028年8月ごろを目安に、上位PyPIパッケージのテストスイートを走らせて壊れないかを見る計画だったが、councilはそれでは遅すぎるとして、もっと早く継続的にやるべきだと求めた。security reviewも、今の記述では足りないとされた。
その後、10月19日にOstrowskiがPEP撤回を発表した。steering councilの基準は高く、いまの版を押し通すだけの余力が自分たちにはない、という説明だった。ただし、free-threaded support や method-based frontend を含む技術方針そのものは支持しており、reference implementation は公開して、撤回されたPEPから参照できるようにするという。Brett Cannonは、main repositoryでの作業は止まるが、コミュニティが別の場所で続けるかどうかは自由だと説明した。もっとも、期限までに別PEPを出すのは現実的ではないとも見られている。結果として、JITは近いうちにCPython mainから外され、Python 3.16の開発初期の段階で問題を早めに拾えるようにする流れになりそうだ。
この件で印象に残るのは、JITそのものの是非より、開発の場をどこに置くかが問題の中心だったことだと思う。Pythonコミュニティは以前から「速くしたい」という要求を無視してきたわけではない。PyPyやGraalPyのような別実装もあるし、NumbaやPyTorchのcompileのような周辺技術もある。それでもCPython本体にJITを載せる意味は、あくまで“標準実装のまま速くなる”ことにある。だからこそ、main branchに入った時点で期待値が一気に上がる。単なる試作品では済まなくなるのだろう。
一方で、steering councilの姿勢もかなり筋が通っていると思う。実験機能を本体に置くと、デバッグやprofiling、instrumentationとの相性、利用者が前提にしていた挙動の変化、セキュリティレビューの抜けなど、後から面倒を見る項目が増える。JITは性能の話に見えやすいが、実際には「いつの間にかふるまいが変わる」危険を伴う。councilが早い段階で止めたのは、完成度が足りないからだけではなく、実験を本体に残すこと自体のコストを見積もり直したからではないかと思う。
PEP 836が置いていた互換性レビューの時期も、今回の話を象徴している。最初のPython 3.17 release candidateに合わせるなら、2028年8月ごろになるはずだった。大きな仕組みとしては筋が通っていても、そこまで待ってから「壊れていました」では遅い。councilが「continuous process」と言い切ったのは、JITのような基盤変更は、最終盤にまとめて検証するのでなく、初期から常時見張るべきだという判断だ。これは単に保守の話ではない。ユーザーのコードが、ある日突然“速くなった代わりに別の挙動になる”可能性をどう扱うか、という話でもある。
ここで厄介なのは、互換性の議論が性能改善より地味に見えることだと思う。だが現場では逆で、互換性の方がずっと重い。ベンチマークで速くても、プロファイラが壊れる、特定の拡張が動かない、パッケージのテストが不安定になる、となれば採用は止まる。しかもCPythonは参照実装なので、他の実装よりも「みんなが期待しているPythonの姿」に近くなければならない。JITはその中心に触る機能だから、速度だけを見ては進めない。councilが早めのレビューを求めたのは、かなり妥当だと感じる。
撤回されたとはいえ、これは「PythonはJITをやめた」という単純な話ではない。作者側は技術方針を否定していないし、reference implementation も残すと言っている。つまり、舞台をCPython mainからどこか別の場所へ移す可能性はある。実際、mainでの実験が止まったとしても、外部で成熟した案が育てば、また戻ってくることはありうる。Pythonの歴史を見ても、いったん退いた案が形を変えて復活することは珍しくない。
ただ、今回の件で明確になったのは、CPython本体で実験を続けるには、相当はっきりした運用計画が必要だということだと思う。性能向上の夢だけでは足りず、どの挙動を守るのか、どこからがバグなのか、誰がどこまで保守するのか、利用者にどう見えるのかまで詰めないと通らない。JITのように期待が大きい機能ほど、説明責任も重くなる。少しもったいない終わり方ではあるが、無理に押し切らず撤回に至ったのは、Pythonらしい慎重さでもある。速くする話と、本体を壊さない話を分けて考えた、その線引き自体は長い目で見て悪くないはずだ。
