对自由线程Python的展望

PEP 703，即自由线程的已接受提案，指出自由线程Python的推广应逐步进行，Python指导委员会在PEP 703接受帖子中对此进行了澄清，这意味着一个跨多个版本的三个阶段过程。因此，重要的是要确保本PEP中的机制适用于自由线程或非自由线程可能是默认或唯一选项的Python解释器。

在撰写本文时，自由线程 Python 处于第一阶段：实验阶段。在此阶段，迫切需要提出的环境标记，以帮助随着包作者逐步添加支持而向自由线程 Python 过渡。

随着支持包数量的增加，特别是在第二阶段：支持但不默认阶段，我们仍然预计对环境标记有强烈的需求，以帮助过渡。

当自由线程Python进入第三阶段：默认阶段时，对环境标记的需求将减少，尽管目前尚不清楚GIL启用的Python是否会完全淘汰（它可能仍然作为非标准构建选项可用）。如果它持续存在，可能会出现对ABI特性检测的逆向需求。

事实上，在所有三个阶段中，包作者可能都需要根据 ABI 功能选择其依赖项的特定版本，随着时间的推移，从默认启用 GIL 转移到默认自由线程。

ABI 功能的设计考虑到了这一点，以确保在不断变化的 Python 生态系统中，在可预见的未来保持有用性和简洁性。

与其他PEP的关系

本PEP扩展了带有ABI特性集语义的环境标记。PEP 751包含了一个类似的扩展，用于锁定文件特定的环境标记；尽管两者是独立开发的，但在新的集合语义方面它们是兼容的。

ABI功能

ABI 特性是 Python 解释器的内在属性，表示为简单易懂的字符串。然而，并非所有特性都同样适用于所有 Python 解释器或 Python 版本。例如，自由线程解释器和 GIL 启用解释器之间的区别仅与 CPython 3.13 及更高版本相关，但解释器的位数与所有解释器都相关。

所有解释器**必须**按所述处理以下 ABI 功能。仅限于特定解释器的 ABI 功能**不得**由其他解释器提供。这些功能分为组，每个组**必须**正好存在一个功能，除非该组被标记为可选，在这种情况下，**必须**最多存在一个功能。

free-threading 或 gil-enabled (仅限 CPython)

如果Python解释器是自由线程的，则free-threading特性**必须**存在，并且gil-enabled特性**不得**存在。否则，gil-enabled特性**必须**存在，并且free-threading特性**不得**存在。

debug (仅限 CPython，可选)

此ABI功能保留用于CPython的--with-pydebug构建。如果解释器是具有Py_DEBUG功能的CPython解释器，则debug功能**必须**存在。在POSIX系统上，这对应于Python表达式"d" in sys.abiflags。

32-bit 或 64-bit (可选)

解释器的位数，即它是 32 位还是 64 位构建[2]。如果位数未知，或者既不是 32 位也不是 64 位，则此功能**不得**存在。

sys_abi_features 环境标记

为了使 ABI 功能在依赖项规范中可用，新的环境标记变量 sys_abi_features 将添加到依赖项指定符的格式中。

为此，我们需要扩展PEP 508中规定并在依赖项指定符中维护的语法，并记录可能的值。

语法通过如下扩充 env_var 的定义来包含 sys_abi_features 标记变量

env_var       = ('python_version' | 'python_full_version' |
                 'os_name' | 'sys_platform' | 'platform_release' |
                 'platform_system' | 'platform_version' |
                 'platform_machine' | 'platform_python_implementation' |
                 'implementation_name' | 'implementation_version' |
                 'sys_abi_features' |
                 'extra' # ONLY when defined by a containing layer
                 )

与语法一样，依赖项指定符中的环境标记概述表也进行了扩充，增加了以下一行

通过这些补充，ABI 功能可以在依赖项规范中通过 in 运算符测试功能的存在，或者通过 not in 运算符测试功能的缺失。

为自由线程Python要求Cython预发布版

若要仅为自由线程Python解释器要求Cython的预发布版本，可以使用以下依赖项规范

cython >3.1.0a1; "free-threading" in sys_abi_features
cython ==3.0.*; "free-threading" not in sys_abi_features

除非在32位 win32 上，否则要求SciPy

若要要求 SciPy，除非在 Windows 上的 32 位解释器上，可以使用以下依赖项规范

scipy; platform_system != "Windows" or "32-bit" not in sys_abi_features

为具有调试功能的自由线程解释器要求NumPy

若要仅为具有调试功能的自由线程解释器要求 NumPy，可以使用以下依赖项

numpy; "free-threading" in sys_abi_features and "debug" in sys_abi_features

审计和更新工具

各种工具都理解以 requirements.txt 文件形式表示的 Python 依赖数据。（例如，Dependabot、Tidelift 等）

此类工具检查依赖数据，并在某些情况下提供工具辅助或完全自动化的更新。我们预计，起初没有任何此类工具会支持新的环境标记，广泛的生态系统支持可能需要数月甚至数年才能实现。

因此，新环境标记的用户在开始使用它们时，其工作流程和工具支持将有所下降。任何新的依赖数据编码位置和方式标准都是如此。

扩展机制

在早期关于该主题的讨论中（自由线程的环境标记），提出了环境标记的通用扩展机制的想法。虽然如果将来出现新的环境标记需求时，可以避免整个PEP流程很吸引人，但存在两个主要挑战。

首先，一个完全动态的机制将给依赖于依赖规范静态分析的工具带来困难。

这意味着，即使采用动态机制，新的环境标记仍可能需要在PEP中明确说明。

其次，引入动态机制将要求打包库中实现更复杂，这将与当前方法有显著不同。

其他环境标记

如果现在需要其他环境标记，则本 PEP 可以扩展以包含它们。

其他工具

参考实现基于 packaging 库和 pip。我们已经确认这允许使用多个构建后端构建和安装包。可能应该将其他工具添加到参考实现中。