怎么了，Python？GIL 被移除、新编译器、optparse 被弃用……-Linuxeden开源社区

怎么了，Python？GIL 被移除、新编译器、optparse 被弃用......

摘要
永远摆脱 GIL 的 Python

LPython：新的 Python 编译器

Pydantic 2 开始可用

PEP 387 定义了 “软弃用”，getopt 和 optparse 已被软弃用

Cython 3.0 发布，提供更好的纯 Python 支持

PEP 722–单文件脚本的依赖关系规范

Python VSCode 支持变得更快

在终端中绘画

没有 GIL 的 Python，永远都是

上个月，”全球译员锁 “再次成为人们关注的焦点。本月，它甚至连 Facebook 的母公司 Meta 也加入了进来：

如果 PEP 703 被接受，Meta 可以承诺以三个[工程师年登陆] nogil CPython 的形式提供支持

很高兴 Python 能得到越来越多的大公司的支持，这些公司都是 Python 的成功受益者。与 2010 年的十年相比，这是一个巨大的反差。

与核心开发人员的内部讨论将讨论推向了高潮，最后官方宣布，PEP 703，即重新点燃战火的提案，将在弄清一些细节后被接受。

这意味着在未来几年，Python 将移除 GIL。

计划是这样的

短期内，一个不支持 GIL 的 Python 实验版本将与常规版本同时发布。目标是 3.13/3.14。

中期，无 GIL 版本被标记为正式支持版本，但仍只是有 GIL 的 Python 的替代版本。宣布了将其作为默认版本的目标日期。这只有在社区对其表示出足够的支持后才会实现，需要几年的时间。

从长远来看，无 GIL 将成为默认设置。在此之前，如果事实证明 no-GIL 项目的投资回报率很低，核心开发人员可以推翻决定，中止该项目。

请注意，如果程序导入了一个在无 GIL 版本中使用 GIL 的 C 扩展程序，它就会自动切换回 GIL。因此，这并不是 2=>3 的情况，即不兼容的代码会被破坏。

采用两种不同构建方式的主要原因是为了管理未知的未知因素。的确，没有人会认为无 GIL 会导致代码崩溃，但对于如此庞大的项目，你永远无法确定。ABI 兼容是个棘手的问题，新的扩展程序需要明确地针对它进行编译才能正常工作，因此社区有必要接受它。

此外，不兼容 GIL 的扩展也能在旧的解释器上运行，因此不会出现 Python 3 代码在 Python 2 上无法运行的情况。

事实上，Python 代码本身应该不会受到影响，而且可以在两种解释器上无缝运行，尽管 GIL 将线程限制在单核上。