作者 | Bite Code
譯者 | Sambodhi
策劃 | 褚杏娟
本文介紹了幾個 Python 相關的更新和新功能。首先，Python 擺脫了 GIL（全局解釋器鎖）。接著，我們看到了 LPython 的發布，這是一個新的 Python 編譯器，同時還有 Pydantic 2 版本的發布，該版本更加可用。接下來，我們討論了 PEP 387，該提案定義了軟棄用，並且 getopt 和 optparse 被軟棄用。緊接著，Cython 3.0 版本發布，對純 Python 支持更加出色。另外，PEP 722 也在文中提及，該提案定義了單文件腳本的依賴規範。最後，我們還討論了在 VSCode 上 Python 支持的改進，以及終端中運行的畫圖程序。這些更新和新功能為 Python 開發者帶來了更多的選擇和便利。
永遠擺脫 GIL 的 Python
上個月，全局解釋器鎖（Global Interpreter Lock，GIL）再次成為關注的焦點。這個月，甚至連 Facebook 的母公司 Meta 都參與其中：
如果 PEP 703 被接受，Meta 將會承諾支持，在 CPython 中提供三名工程師年的 nogil（無 GIL）支持。（註："engineer years" 指的是一名工程師在一年內的工作時間。）
如果 PEP 703 被接受，Meta 將會承諾支持，在 CPython 中提供三名工程師年的 nogil（無 GIL）支持。（註："engineer years" 指的是一名工程師在一年內的工作時間。）
很高興看到越來越多的大公司為 Python 的成功做出貢獻。與 2010 年代相比，這是一個巨大的變化。
關於 PEP 703 的討論在核心開發人員中達到高潮，最後做出了一個正式聲明，即將接受重新點燃激情的提案，但需要解決一些細節問題。
這意味著在未來幾年內，Python 將擺脫全局解釋器鎖。
以下是計劃：
- 短期內，將同時發布一個不受支持的實驗性 Python 版本，該版本不包含 GIL，目標版本是 3.13/3.14。
- 中期內，將標記無 GIL 版本為正式支持版本，但仍然是 Python 帶有 GIL 版本的替代品。將宣布一個目標日期，使其成為默認版本。這將只會在社區表現出足夠支持的情況下發生，並將需要幾年的時間。
- 長期內，無 GIL 版本將成為默認版本。在此之前，核心開發人員可以撤銷該決定並中止無 GIL 項目，如果該項目被證明回報率不佳。
請注意，如果程序導入了一個單一的使用 GIL 的 C 擴展，在無 GIL 版本的構建中，它將自動切換回 GIL 版本。因此，這不是一個 2=>3 的情況，不會導致不兼容的代碼破壞。
兩種不同的構建版本的主要原因是管理未知的未知情況。事實上，沒有人預料到無 GIL 會出現問題，但對於如此大的項目，你永遠無法確定。ABI 兼容性很複雜，新擴展需要針對其進行顯式編譯，才能使其正常工作，所以需要社區的支持。
而且，無 GIL 兼容的擴展將在舊解釋器上工作，因此不會出現類似 Python 3 代碼不適用於 Python 2 的情況。
實際上，Python 代碼本身不應受到影響，並且在其中一個版本上或另一個版本上都可以無縫工作，儘管在帶有 GIL 的版本中線程被限制在單個核心上。
LPython：一個新的 Python 編譯器
這是我沒有預料到的消息。在《CPython、Pypy、MicroPython、Jython 是什麼鬼？》（What's the deal with CPython, Pypy, MicroPython, Jython...?）這篇文章中，我們討論了 Python 編譯器，我認為我在列舉所有重要內容方面做得相當不錯。然而，LPython 團隊決定在此基礎上繼續擴展。
LPython 是一個新的 BSD 3 編譯器，它可以將 Python 代碼翻譯為 LLVM、C、C++ 或 WASM。它的目標不是編譯整個程序，雖然它也能做到，但更像是 numba 和 cython 一樣，讓你加速數值瓶頸。基準測試非常有希望，並且在 AOT（Ahead-of-Time）和 JIT（Just-in-Time）之間切換的能力非常方便，儘管你仍然需要在機器上安裝整個編譯鏈。LPython 喜歡原始的 Python 代碼，因此如果在片段中調用 Python 函數，你必須使用裝飾器顯式標記它為 Python 函數。因此，大多數人可能會將其用於非常具體的代碼片段。
Pydantic 2 變得更加可用了
我一直在宣傳 Pydantic 的第二個版本的到來，因為我和很多人都經常使用它進行數據驗證和架構定義，而新版本更加快速。
沒錯，它上個月發布了穩定版，但如果你讀過《緩解你的 Python 打包痛苦》（Relieving your Python packaging pain），你會知道我不鼓勵人們使用最新版本的東西，除非用於測試或者娛樂。
事實上，即使是穩定的主要版本，也仍然需要完善，並且社區支持較少。
但現在發生了兩件事情：
- Pydantic 2.1 已經發布，第一批糟糕的錯誤已經被消除。
- Fast API 宣布支持 Pydantic 2。因為它是 Pydantic 使用的最大推動力，所以這是一個里程碑。
現在，我將嘗試在一個個人項目中使用它，如果有效，幾個月後再將其應用於專業項目中。
PEP 387 定義了「軟棄用」，getopt 和 optparse 被軟棄用
如果你還沒有閱讀 Victor Stinner 的博客，我鼓勵你去讀一下。這是一篇技術性和原汁原味的博文，毫不摻雜廢話，讓你能夠深入了解核心開發人員的貢獻生活。最新一篇文章提到了我在上個月忽略的一件事：軟棄用已被添加到 PEP 387——向後兼容性策略。
這份於 2009 年創建的文檔規定了 Python 項目如何處理棄用問題，現在它將包含以下內容：
當使用一個不應再用於編寫新代碼的 API 時，可以使用軟棄用，但在現有代碼中繼續使用它仍然是安全的。該 API 保持文檔化和測試，但將不再進行進一步開發（沒有增強功能）。「軟」棄用和（常規的）「硬」棄用的主要區別在於，軟棄用不意味著計劃移除被棄用的 API。
當使用一個不應再用於編寫新代碼的 API 時，可以使用軟棄用，但在現有代碼中繼續使用它仍然是安全的。該 API 保持文檔化和測試，但將不再進行進一步開發（沒有增強功能）。「軟」棄用和（常規的）「硬」棄用的主要區別在於，軟棄用不意味著計劃移除被棄用的 API。
基本上，軟棄用的 API 處於殭屍狀態，永遠維持存活狀態，但將不會有任何進一步的開發工作，並明確建議不再使用它。
optparse 和 getopt 是兩個曾經是解析腳本參數的事實標準解決方案的模塊，現在被標記為"軟棄用"。你可以永遠使用它們，但你可能不應該這樣做。
首先，argparse 是更現代的標準庫解決方案，我們有一篇很好的文章介紹它。
其次，第三方項目如 typer 和 click 也存在。
Cython 3.0 發布，支持純 Python 更好
Cython，最著名的 Python 編譯器，發布了 3.0 版本。雖然此版本帶來了各種改進，但有一個特別突出。Cython 以前一直存在一些限制：它使用 Python 的超集來表達其中的一些功能。
但根據發布說明，這已不再是問題：「現在應該可以用普通 Python 語法來表達所有 Cython 代碼並使用所有功能」。
這意味著現在你應該能夠使用任何 Python 代碼庫，只需全部使用 Cython 並觀察結果。
PEP 722 - 單文件腳本的依賴規範
儘管無 GIL 話題仍然活躍，但 PEP 722 的提議確實激發了更多的討論。
該提案旨在通過注釋中的一種形式化語法，類似於 Groovy 的語法，來表達單個腳本的依賴關係。參考 PEP 本身中的示例：
import requestsfrom rich.pretty import pprint
resp = requests.get("https://peps.python.org/api/peps.json")data = resp.json()pprint([(k, v["title"]) for k, v in data.items()][:10])
重要的部分是：
現在這將被正式規範化，以便由第三方工具解析。這個概念並不新鮮，像 pip-run 這樣的工具已經支持運行一個腳本，而你可以使用此類注釋來描述其依賴關係：
這些包將被安裝在臨時虛擬環境中，並在運行後被刪除，類似於 JS 世界中 npx 的做法。
這個 PEP 並不意味著 Python 或 pip 會集成這樣的功能，目前只是在形式上對語法進行規範化。但我對這個提案有很大的希望，因為我有幾個獨立的 Python 腳本散落在那裡，這樣的功能對它們會有很大的好處，特別是如果未來可以保留這個虛擬環境。這樣的提案可能顯示出對此功能的需求，幾年後，可能會導致 pip 採納。例如，npx 影響了 npm create 的添加，允許從特定的包中獲取項目模板。事實上，這是 npx 最常見的用例。
Python 在 VSCode 上的支持變得更加快速
如果你使用 VSCode，你可能已經注意到使用許多代碼檢查器會使 IDE 變得更慢。其中，Mypy 尤為緩慢，因為啟動 mypy 命令的速度較慢，並且 VSCode 不使用它的守護進程模式。
但在新版本中，現在有了一個新的官方 mypy 擴展，它使用了 dmypy 守護進程。速度提升非常顯著，編輯器現在可以對整個代碼庫進行檢查，而不僅僅是當前文件。
此外，微軟官方的 Python 支持擴展 pylance 將會持久化它在第三方庫上執行的所有索引工作。這將導致更輕快的啟動，對於大型項目而言，由於索引可能需要較長時間，特別是在運行速度較慢的計算機上，這將帶來更快的體驗。我個人必須在不允許修改的企業客戶的筆記本電腦上工作，它們配備了大量的安全軟體，這使得它們變得非常緩慢，每次點擊任何東西後都會進行進程檢查和網絡調用來檢查文件簽名。因此這真是拯救了生命。
在終端中繪製畫面
這真是太酷了：
這是一個在終端中運行的畫圖程序，藉助 Python 庫 textual 實現。
這可能不會改變你的生活，但太酷了。
我安裝了它，反應速度真是快。它甚至可以處理 Ctrl-Z，並且在嘗試保存作品時還提供了文件選擇器。
原文連結：
https://www.bitecode.dev/p/whats-up-python-the-gil-removed-a
聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。
點擊底部閱讀原文訪問 InfoQ 官網，獲取更多精彩內容！
今日好文推薦
都在追「新潮」技術，但你有大廠們的動作快嗎？
大模型競爭突然升級！亞馬遜 CEO 親自監督、組建新的核心技術團隊，集中優勢資源打造「最具野心」的大語言模型
一場 AI 引發的開源革命迫在眉睫？Hugging Face 更改文本推理軟體許可證，不再「開源」
「Twitter如今就像瘋人院！」睡地板仍被裁女高管爆料：馬斯克帶來「恐懼文化」，被裁是最大解脫