CPython JIT 開發暫停，等待標準軌道 PEP

CPython JIT 開發停滯，等待正式 PEP

Python 指導委員會（Python Steering Council）已正式要求暫停在 CPython 主分支中為實驗性的即時編譯器（Just-In-Time, JIT）加入新功能、優化與效能工作。此凍結狀態將持續有效，直到一份標準軌道 Python 改進提案（Standards Track PEP）被撰寫、討論並由委員會正式接受，以將 JIT 從實驗狀態轉型為語言執行環境中受支援且非實驗性的部分。

雖然新功能開發已暫停，但指導委員會澄清，JIT 的錯誤修復與安全性修復仍可照常進行。

需要標準軌道 PEP 的原因

目前的 JIT 實作是作為一項實驗併入主分支的，其指導方針為 PEP 744，該提案被指定為「資訊性」（Informational）而非標準軌道提案。指導委員會指出，JIT 編譯器的複雜度與影響範圍需要社群共識與正式承諾，而資訊性 PEP 無法提供這些。

為了繼續推進，委員會要求一份新的 PEP，必須解決以下關鍵領域：

長期維護與永續性

由於 JIT 子系統的規模與複雜度，該 PEP 必須概述一份清晰的長期永續性計畫。這包括 JIT 將如何被維護，以及其維護工作對那些不直接參與 JIT 開發的核心貢獻者所產生的具體影響。

工具與功能相容性

提案必須定義 JIT 如何與現有的 CPython 功能與工具互動，並保證其相容性。具體的關注領域包括：

• Free-threading
• Profilers
• Debuggers

成功指標與時間表

委員會預期該專案會有清晰、可衡量的目標，包括具體的效能目標、平台覆蓋範圍要求，以及記憶體開銷限制，並附帶達成這些里程碑的時間表。

生態系統整合

該 PEP 必須澄清 JIT 與第三方 JIT 實作（例如 Numba、PyTorch 與 CinderX）之間的關係。委員會建議，與其提供單一的具體實作，該 PEP 或許可以描述一種能夠支援多種實作策略的通用 JIT 基礎設施。

時間表與不符合要求的後果

指導委員會已設定了一個六個月的窗口期，用於提交並解決一份 PEP。如果在該時間範圍內沒有任何標準軌道 PEP 被接受，JIT 程式碼必須從 CPython 主分支中移除，並所有進一步的開發必須在主 Python 專案之外的獨立儲存庫中進行。

社群反應與技術辯論

此公告引發了開發者之間關於工程嚴謹性與開發動能之間的平衡問題的顯著辯論。

支持凍結的觀點

一些貢獻者認為，此舉是為了防止 CPython 程式碼庫變得過於複雜且缺乏清晰維護計畫的必要工程標準應用。一位評論者指出，鑑於先前實驗性功能所產生的問題（例如「YOLO GC debacle」），此舉是合理的。

反對凍結的觀點\n批評者認為，在技術進步的關鍵時刻停止開發可能會扼殺專案的動能。一些觀察者認為，要求提供通用「基礎設施」而非特定實作的要求，是一種「毒藥膠囊要求」（poison-pill requirement），旨在讓 JIT 更難以整合。

對 Python 效能的看法

社群中的討論凸顯了關於 Python 效能哲學的分歧：

"CPython 的賣點在於其簡單、效能足以搭配 C 擴充功能使用，且程式碼是可存取的。為了偶爾 50% 的速度提升（以及退化 ...）而使程式碼庫變得複雜，並不值得。"

其他開發者則表達了希望 JIT 最終能超越預設解釋器，並指出在從 Python 2 轉向 Python 3 的過程中也曾見過類似的軌跡。