CPythonのJIT、PEP 836の取り下げで削除へ

標準のPythonインタープリターであるCPythonの実験的なJIT（ジャストインタイム）コンパイラが、プロジェクトのmainブランチから削除される見通しです。JITを正式な機能にするための提案だったPEP 836を、その作成者が2026年10月19日に取り下げました。LWN.netは10月26日、コードは「かなり早く」削除される可能性が高く、理想的にはPython 3.16の開発サイクルの早い段階になると報じました。これにより、インタープリターに組み込んだコンパイラで標準のPythonを高速化する取り組みは、ひとまず終わります。

JITは、頻繁に実行されるPythonコードを、プログラムの実行中にマシンコードに変換します。Python 3.15の公式のWindows版とmacOS版のビルドには、実験としてJITが含まれていますが、デフォルトでは無効になっています。

ここまでの経緯

きっかけは、2026年6月5日のPython運営評議会（Steering Council）による発表でした。運営評議会は、この言語を統治するグループです。評議会は、JITをCPythonのサポート対象の一部とする根拠を示す正式な提案を求めました。これはStandards Track PEP（Python Enhancement Proposal）と呼ばれるものです。

評議会は、厳格な条件を定めました。

ルール	内容
JITの新しい作業	PEPが承認されるまで、mainでの新機能、最適化、性能改善の作業は行わない
引き続き許可されるもの	バグ修正とセキュリティ修正
期限	PEPを提出し、結論を出すまでに6か月
PEPが承認されなかった場合	「JITのコードはmainブランチから削除されなければならない」
Python 3.15	評議会は「3.15については現状維持で問題ない」とした

評議会は、JITチームがプロセスを迂回したとは考えていないと述べました。評議会自身がプロセスについて十分に厳格でなかったことも認めました。

PEP 836の提案内容

Savannah Ostrowski氏、Ken Jin氏、Brandt Bucher氏が、Python 3.16を対象とした「JIT Go Brrr」という題のPEP 836を書きました。このPEPは、JITをすぐにサポート対象と宣言するよう求めたものではありません。測定可能な目標を伴う、期限付きの道筋を提案しました。

• GILあり： 1年目に、JITビルドが通常のインタープリターより少なくとも5%高速になること。GIL（グローバルインタープリターロック）とは、一度に1つのスレッドしかPythonコードを実行できないようにするロックです。
• フリースレッド： Python 3.17の最初のベータ版までに、フリースレッド版のインタープリターより少なくとも20%高速になること。
• 設計の変更： 頻繁に実行されるコードのトレースを記録する方式から、メソッド全体をコンパイルする方式に移行すること。

LWNによると、評議会は9月21日に回答しました。評議会は、PEPが自らの疑問に答えていると述べましたが、一部の回答はそれほど説得力がないとしました。それでも、セキュリティ、プラットフォームのサポート、ユーザーから見える挙動について、さらに詳しい説明を求めました。3.17の最初のリリース候補で予定されていた互換性レビューについては、「あまりにも、あまりにも遅すぎる」と評しました。

InfoWorldによると、評議会は、PEPには長期的なサポート、性能テスト、デバッグツールについての詳細が欠けているとも述べました。速度の目標については、楽観的すぎるとしました。

作成者が取り下げた理由

InfoWorldが引用したところによると、Ostrowski氏は「現在のバージョンを前に進めるだけの個人的な余力が、私たちにはないと感じています」と書きました。「この規模の提案に対して、運営評議会が高い基準を設けるのは当然のことです」とも付け加えました。チームは今も「PEPで示した技術的な方向性」を信じていると、同氏は述べました。

LWNは、Ostrowski氏がPython 3.16と3.17のリリースマネージャーであることを指摘しています。取り下げの投稿では、リファレンスコードを公開し、PEPからリンクするとしていました。

性能の向上は本物でしたが、控えめなものでした。PEP 836によると、Python 3.15の高速化は、主要なプラットフォーム全体の幾何平均で4%から12%でした。InfoWorldによると、その効果が主に表れたのは、長時間実行されるタイトなループなど、一部の種類のプログラムでした。

開発者にとっての意味

ほとんどのPythonユーザーはJITを有効にしたことがないため、日常的なコードには影響しません。それでも、一部のグループは対応が必要です。

• Python 3.15は変わりません。 評議会は3.15について現状維持を受け入れました。現在 PYTHON_JIT=1 を設定している場合、そのリリースでは引き続き動作します。
• 3.16でのJITを前提に計画しないでください。 削除は3.16の開発サイクルの早い段階で行われる見通しです。3.15で測定した高速化は、一時的なものとして扱いましょう。
• ビルドはよりシンプルになる見込み。 JITビルドには、ビルド時にコンパイラツールキットであるLLVMが必要です。Pythonをソースからビルドしているチームは、今後その手順を省ける可能性が高いでしょう。
• 速度は他の手段で。 評議会自身が、CinderX、Numba、PyTorchといった別のJITプロジェクトを挙げました。まずコードをプロファイリングし、そのうえでホットパスに合ったツールを選びましょう。
• フォークでは続く可能性があります。 LWNによると、Brett Cannon氏は、mainでの作業を止めても、他の場所での作業まで止まるわけではないと述べました。JITが復活したとしても、戻ってくるには同じ高い基準を満たす必要があります。

Python 3.15.0は10月9日に公開されました。より高速になったJITは、その主な変更点の一つでした。それから3週間もたたないうちに、その同じJITには正式な機能になる道がなくなりました。