Python 團隊官宣下線 GIL

作者 | 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" 指的是一名工程師在一年内的工作時間。）

很高興看到越來越多的大公司為 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 處于僵屍狀态，永遠維持存活狀态，但将不會有任何進一步的開發工作，并明确建議不再使用它。

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 本身中的示例：

# In order to run, this script needs the following 3rd party libraries
#
# Requirements:
#    requests
#    rich




import requests
from 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])           

重要的部分是：

# Requirements:
#    requests
#    rich           

現在這将被正式規範化，以便由第三方工具解析。這個概念并不新鮮，像 pip-run 這樣的工具已經支援運作一個腳本，而你可以使用此類注釋來描述其依賴關系：

$ pip uninstall rich requests
WARNING: Skipping rich as it is not installed.
WARNING: Skipping requests as it is not installed.
$ pip-run dah_script.py
[
│   ('1', 'PEP Purpose and Guidelines'),
│   ('2', 'Procedure for Adding New Modules'),
│   ('3', 'Guidelines for Handling Bug Reports'),
│   ('4', 'Deprecation of Standard Modules'),
│   ('5', 'Guidelines for Language Evolution'),
│   ('6', 'Bug Fix Releases'),
│   ('7', 'Style Guide for C Code'),
│   ('8', 'Style Guide for Python Code'),
│   ('9', 'Sample Plaintext PEP Template'),
│   ('10', 'Voting Guidelines')
]           

這些包将被安裝在臨時虛拟環境中，并在運作後被删除，類似于 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