Japanese Translation:

Python Steering Council は、CPython のメインブランチにおける実験的なジャストインタイム（JIT）コンパイルの開発を実質的に停止した。当初、Brandt Bucher によって 2024 年初頭に Python 3.13 向けに追加されたものだが、正式な標準化プロセスの提案としては承認されておらず、非公式トラックの下で進められてきた。その後、正式承認を求めるリクエストを受け、7 月に PEP 836（「JIT Go Brrr」）が提出された。コミュニティからのフィードバックとして、提案を分割すべきという指摘や、支持計画の不明確さ、楽観的なパフォーマンス主張、不十分なセキュリティ審査、そして互換性のマイルストーンを逃したこと（特に Python 3.17 のスケジュールに相対的に設定された 2028 年 8 月のレビュー日）が挙げられた。これにより、Steering Council は同プロジェクトに必要な厳格さやコミュニティの合意が欠如していると判断した。その結果、限られたコントリビューターの帯域幅を理由として PEP 836 は 10 月に取り下げられ、Brett Cannon が、完全な審査を受けた実装が他で行われるまで、メインリポジトリでの JIT 作業は停止することを確認した。既存の問題を早期に解決するため、JIT コードは近々 CPython のメインブランチから削除される見込みであり、関連するバグは Python 3.16 の開発サイクル中に浮上すると予想される。利用者は今後しばらくの間、実験的なスピードアップではなく、既存の最適化ツールに依存することを推奨される。

Python 3.13 の実験的 JIT コンパイラ開発が PEP 撤回で終了へ

概要

Python 3.13 で CPython に追加された実験的な JIT（Just-In-Time）コンパイラの開発が、正式な規格案（PEP）の作成に失敗したことを理由に、一時的停止から恒久的な終了へと至りました。

6 月: ガイド理事会より、保守性と互換性への懸念を解消する「明確な成功指標」と「完了スケジュール」が示された正式な PEP の承認を求められました。
7 月 -9 月: 新規 PEP（PEP 836）の作成と議論が行われましたが、合意形成には至らず開発は低迷しました。
10 月: PEP 作成者らが理事会への承認追求を中止し、プロジェクト開発は事実上終了となりました。

背景：非公式な導入からの混乱

CPython メインブランチへの JIT コンパイラ追加は、2024 年初頭にブランドト・ビューハー氏による非公式なマージで開始されましたが、手順の欠陥が原因となりました。

正式手続きの欠如: 大規模機能導入には理事会承認を得た正式な PEP が必須ですが、初期段階ではこの手続きを踏んでいませんでした。
- リリースマネージャーの Thomas Wouters 氏が理事会メンバーとして介入し、正式な PEP の作成と提出が求められました。
情報提供型 PEP から本格的な提案へ:
- 当初は機能進捗報告のみを目的とした「PEP 744（情報提供型）」が草案されました。
- 理事会はこれを「単なる願望」ではなく、「支援済み機能としての保証内容・保守コミットメント」として位置づけるべき正式な PEPの作成を要請しました。

PEP 836 の議論と困難

理事会からの要望を受け、ビューハー氏らにより PEP 836「JIT コンパイル」が作成されましたが、複数の技術的・組織的課題が発生しました。

1. PEP 分割の議論

意見: シャノン氏らから「草案は本来なら二つの異なる PEP に分けるべきだ」との指摘がありました。
- 理由：JIT ワークの受容目標に焦点を当て、実装の詳細は含める必要はないため。
反論: ビューハー氏とオストロフスキィ氏は「目標を支える計画や検討内容を共有できないのは不安だ」「計画がない目標は単なる願望だ」と構造擁護を行いました。

2. コンセプトの曖昧さへの批判

理事会は PEP が以下の点について「過度に楽観的」または「具体性に欠ける」と指摘しました。

支援計画・パフォーマンス基準: 十分に具体的ではなく、他領域についても曖昧。
ユーザーへの影響: 「他の Python 実装でも同様」な差異をどう扱うか明確化が必要（バグ判定や回避策の提示不足）。
プラットフォーム互換性: 新しいプラットフォームへの拡張性や、プラットフォーム固有知識なしでの維持保証が不明確。
セキュリティ対応: セキュリティレビューを含めるべきとの指摘が出ているが、現状では不十分。
- Python セキュリティ対応チームとの議論とセキュリティレビューの実施が必要と提案されました。

3. 開発プロセスへの懸念

期限の厳格化: 当初予定されていた「2028 年頃」の互換性レビューマイルストーンは、「非常に遅すぎる」と批判され、早期かつ継続的なプロセス開始が求められました。
コミュニティ合意の欠如: CPython の広範な開発者グループによる厳格なレビューを経ない設計判断が行われている点が問題視されました。
- 理事会は「この PEP に言及する前にコミュニティの支持や合意を測りたい」と強調しました。

結論：プロジェクト終了と今後の展望

慎重な検討の結果、PEP の作成者らは理事会への承認追求を中止し、撤回しました。

撤退理由: ガイド理事会が設定する高い基準に対し、現在の人的リソースでは対応できないため。
- 「技術的な方向性（自由スレッド化など）への信託は継続」しつつも、正式な PEP の承認は得られなかった。
今後の扱い:
- CPython メインブランチからの除外: 問題の早期発見を確保するため、Python 3.16 の開発初期段階よりメインブランチから JIT コードが排除されます。
- コードの公開: 参照実装は引き続き公開され、撤回された PEP にリンクを付けて調査・拡張への道筋を提供します。
将来性:
- 推進者が引き続き取り組むかは不明。
- コミュニティから十分な関心が得られる場合は他者に引き継がれる可能性はあるが、当初の著者らが全員関係しているため代替 PEP の提出は低いと見られています。

まとめ: Python コアへの実験的機能導入において、**「理事会承認を得た正式な PEP の欠如」**が致命的要因となり、保守性・互換性・セキュリティなどの懸念を解消する基準を満たせなかったことが開発終了につながりました。

Python の実験的な JIT が削除される予定