Python 团队官宣下线 GIL

本文介绍了几个 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 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])

重要的部分是：

# Requirements:#    requests#    rich

现在这将被正式规范化，以便由第三方工具解析。这个概念并不新鲜，像 pip-run 这样的工具已经支持运行一个脚本，而你可以使用此类注释来描述其依赖关系：

$ pip uninstall rich requestsWARNING: 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，并且在尝试保存作品时还提供了文件选择器。