本文介绍了几个 Python 相关的更新和新功能。首先，Python 摆脱了 GIL（全局解释器锁）。接着，我们看到了 LPython 的发布，这是一个新的 Python 编译器，同时还有 Pydantic 2 版本的发布，该版本更加可用。接下来，我们讨论了 PEP 387，该提案定义了软弃用，并且 getopt 和 optparse 被软弃用。紧接着，Cython 3.0 版本发布，对纯 Python 支持更加出色。另外，PEP 722 也在文中提及，该提案定义了单文件脚本的依赖规范。最后，我们还讨论了在 VSCode 上 Python 支持的改进，以及终端中运行的画图程序。这些更新和新功能为 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 的版本中线程被限制在单个核心上。
这是我没有预料到的消息。在《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 的第二个版本的到来，因为我和很多人都经常使用它进行数据验证和架构定义，而新版本更加快速。
没错，它上个月发布了稳定版，但如果你读过《缓解你的 Python 打包痛苦》（Relieving your Python packaging pain），你会知道我不鼓励人们使用最新版本的东西，除非用于测试或者娱乐。
事实上，即使是稳定的主要版本，也仍然需要完善，并且社区支持较少。
但现在发生了两件事情：
现在，我将尝试在一个个人项目中使用它，如果有效，几个月后再将其应用于专业项目中。
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 并观察结果。
尽管无 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])
重要的部分是：
现在这将被正式规范化，以便由第三方工具解析。这个概念并不新鲜，像 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，并且在尝试保存作品时还提供了文件选择器。
原文链接：
https://www.bitecode.dev/p/whats-up-python-the-gil-removed-a
声明：本文为 InfoQ 翻译，未经许可禁止转载。
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
