所以 Python 3.14 昨天終於正式發布了。終於移除了 GIL（全局解釋器鎖），這使得多線程代碼的執行速度大幅提升，而不必處理多進程或其他繁瑣的變通方法所帶來的腦力負擔和開銷。而且 uv 已經完全支持它，這真是令人驚訝。 不過，我有點沮喪，因為我正在進行的主要項目有大量的庫依賴，對於新版本的 Python，特別是像 3.14 這樣革命性和不同的版本，主線支持總是需要很長時間。 所以我已經準備好在不確定的未來忍受 GIL 地獄。 但我想，為什麼不呢？讓我看看 codex 和 GPT-5 是否能夠克服這一切。所以我備份了我的設置，並請 codex 嘗試，給它 uv 團隊最近的博客文章作為起點。 有一些主要的障礙。我使用 PyTorch，這個庫更新得非常慢。而且 pyarrow 也不支持 3.14。cvxpy 也是，這是凸優化庫的包裝器。 儘管如此，我還是想看看即使我們不得不處理一些庫的“供應商”問題，並從 C++、Rust 等語言從頭構建一些東西，使用最新的夜間 GitHub 存儲庫，而不是通常的 PyPi 庫，我們能做些什麼。 我告訴 codex 去搜索網絡，閱讀 GitHub 問題頁面等，以便我們不會不必要地重新發明輪子（或者我應該說 WHL，🤣）。 為什麼不呢？我可以隨時測試，如果我無法讓它工作，那我可以退回到 Python 3.13，不是嗎？沒有損失，沒有傷害。 好吧，這花了很多小時的工作，幾乎所有的工作都是由 codex 完成的，而我偶爾檢查一下，但它成功地讓一切運行起來了！ 當然，這需要多次迭代，我不得不調整一些東西以避免煩人的棄用警告（其中一些來自其他庫，所以我最終不得不過濾它們）。 但這些庫會隨著時間的推移而更新，以更好地支持 3.14，最終我將不需要使用這些煩人的變通方法。 Codex 甚至建議將編譯的 whl 藝術品上傳到 Cloudflare 的 R2（像 s3 一樣），這樣我們就可以輕鬆地在多台機器上重用它們，並為我處理了所有細節。我自己永遠不會想到這一點。 每當出現另一個複雜或問題（例如，下面截圖中顯示的情況），codex 都能輕鬆解決，毫不費力地克服所有困難。 如果你從未在 LLMs 出現之前的“壞舊日子”中嘗試過這樣的事情，那是一種不被感激的磨難，可能會耗費數天，然後遇到障礙，導致完全失敗。 所以大多數時候，嘗試這樣的事情實在是太冒險了；你不如等 6 或 9 個月讓事情變得簡單一些。 無論如何，我仍然無法真正相信這一切都在運行！我們正生活在未來。

當你意識到這條推文可能會表現良好時：