Python JIT 暫停後，3.15 先看這 5 件事

Python 的 JIT 編譯器已暫停推進，接下來要看新 PEP 能否在 6 個月內通過。

這份清單幫你判斷：Python 3.15 的效能承諾還值不值得期待、JIT 目前到底能不能用、以及 CPython 團隊接下來會往哪個方向走。看完這 5 點，你就能分得出這是一次短暫停車，還是架構路線要重寫。

1. JIT 已經不是主線推進項目

Python steering council 已要求，在新的 PEP 被建立並接受之前，主線上的 JIT 開發先暫停。這不代表整個專案停擺，但代表新的功能性改動暫時不能再往前推。

可以繼續進行的，主要是修 bug 和安全修補。若 6 個月內沒有通過新提案，現有 JIT 程式碼預期會從 main 移除。

• 新功能開發：暫停
• Bug 修補：可繼續
• 安全修補：可繼續
• 移除條件：6 個月內無核准 PEP

2. 3.15 的 8-9% 效能提升仍是實測目標

JIT 原本被視為 Python 3.15 的亮點之一，目標是在 x86-64 Linux 上帶來 8-9% 的幾何平均效能提升。對許多開發者來說，這是最直接也最容易理解的價值。

但它目前仍是實驗性功能，而且預設關閉。若要啟用，必須在環境變數中設 PYTHON_JIT=1，也就是說它還不是一般部署會默認使用的執行路徑。

• 目標平台：x86-64 Linux
• 宣稱提升：8-9% 幾何平均
• 預設狀態：關閉
• 啟用方式：環境變數

3. 爭議核心不是流程，而是專案邊界

steering council 認為，這種規模的變更不應在沒有正式 PEP 的情況下合併。現有的 PEP 744 屬於資訊型文件，還留下不少需要更明確回答的問題。

這些問題包括誰負責維護、如何跟 CPython 工具鏈協作、成功標準怎麼定，以及它和第三方 JIT 方案的關係。換句話說，這不只是文件形式之爭，而是要先把專案邊界畫清楚。

• 維護責任
• 工具鏈相容性
• 成功標準
• 與其他 JIT 的關係

4. 團隊要的是緩衝期，不是整個重來

核心貢獻者 Mark Shannon 的立場很明確：如果立刻全面停工，團隊會被迫倉促寫新提案，反而少了足夠的社群討論。他認為新 PEP 本來就打算晚些時候再提出，屆時性能論證也會更完整。

他也提醒，若直接進入長期停擺，會拖慢節奏並流失新貢獻者。若改在 fork 上繼續做，因為優化機制會造成大量程式碼分歧，維護成本也會很高。

• 希望的緩衝：1 到 2 個月
• 主要風險：失去動能
• fork 問題：程式碼分歧太大

5. 最可能走向是更通用的 JIT 架構

steering council 成員 Pablo Galindo Salgado 的說法透露出一個方向：不是逼大家選邊站，而是希望有一套能支援多種實作策略的 JIT 基礎設施。這表示未來設計可能會更鬆耦合。

Donghee Na 也認為現在正是補上正式 PEP 的好時機；Thomas Wouters 則補充，6 個月期限不是死線，但這件事必須被認真處理。這些訊號都指向同一件事：JIT 不一定被否定，但它需要更清楚的長期形狀。

• 可能方向：共享 JIT 基礎設施
• 設計偏好：降低耦合
• 期限態度：有彈性，但不是可忽略

哪種人該盯這件事

如果你在意短期 Python 效能，重點是看新 PEP 能不能在 6 個月內過關，以及 3.15 的 JIT 承諾會不會保住。如果你更在意可維護性，那麼維護權責、工具鏈整合和成功標準，才是這次爭議真正的核心。

對一般使用者來說，現在最實際的結論很簡單：JIT 仍是實驗性功能，預設還是關閉，大多數部署不需要立刻改設定。對 CPython 貢獻者來說，下一份 PEP 會決定它是正式路線，還是被迫改寫的起點。