指導委員會暫停開發並要求正式提案
Python 指導委員會於六月宣布暫停 CPython 主分支中實驗性 JIT 編譯器的開發工作，直到有一份經過批准的 Python 增強提案（PEP）能解決維護、相容性及明確的成功指標與時間表等疑慮。該 JIT 功能由 Brandt Bucher 於 2024 年初加入 CPython 3.13 版本，當時僅透過資訊性 PEP 744 進行說明，並未經過標準軌道 PEP 的正式批准程序。
委員會成員 Thomas Wouters 指出，暫停開發並非因單一觸發事件，而是為了確保 JIT 工作不會干擾其他專案，例如與插樁、除錯及效能分析工具的整合。此外，外部 JIT 方案如 CinderX，以及 Numba 和 PyTorch compile 等相關技術的討論，也促使委員會重新評估內建 JIT 的定位。
PEP 836 提案遭質疑缺乏具體承諾
為回應委員會要求，Bucher、Savannah Ostrowski 與 Ken Jin 起草了 PEP 836（「JIT Go Brrr：通往 CPython 支援 JIT 編譯器之路」），並於七月發布徵求意見。然而，社群討論中出現批評聲音，認為該提案應拆分為兩個獨立的 PEP，一個僅涵蓋接受 JIT 工作的目標，另一個則處理實作細節。
指導委員會在九月的聲明中指出，PEP 836 雖然回答了大部分問題，但在支援計畫、效能標準方面不夠具體，且在多個領域的描述過於模糊或樂觀。委員會列出了十項需要明確說明或討論後拒絕的項目，涵蓋記憶體影響、安全性以及平台一致性等關鍵議題。
技術限制與使用者行為差異疑慮
委員會特別關注 JIT 啟用後對使用者可見行為的影響，認為 PEP 836 對此過於樂觀。許多 Python 程式碼依賴直譯器設計中的特定特性，若 JIT 導致行為改變，需明確界定這些差異是否視為錯誤以及處理方式。此外，委員會要求將相容性審查的時間點從預定的 Python 3.17 發布候選版本（約 2028 年八月）大幅提前，並建議改為持續進行的過程。
在安全性方面，委員會認為 PEP 中對該領域的探討不足，建議應與 Python 安全回應團隊討論，並將安全性審查納入支援狀態的評估標準。同時，委員會擔心 JIT 的設計決策未經負責 CPython 開發與維護的更大範圍開發者群體進行關鍵審查。
作者撤回提案並移除主分支程式碼
經過考慮後，PEP 836 的作者決定不再追求委員會的批准。Savannah Ostrowski 於十月十九日宣布撤回該 PEP，表示雖然相信技術方向正確，包括對自由執行緒（free-threaded）的支持和方法型前端，但團隊缺乏足夠的人力資源來推動當前版本的提案。
隨著 PEP 被撤回，JIT 程式碼預計將很快從 CPython 主分支移除，以確保相關問題能在 Python 3.16 開發週期早期得到處理。Brett Cannon 指出，由於所有積極推動 JIT 工作的人員都是該 PEP 的作者或貢獻者，因此不太可能有替代提案在截止日期前提交。目前尚不清楚原驅動團隊是否會繼續在其他地方進行開發，還是僅將參考實作開放給社群探索。
