摘要

本 PEP 概述了在调用 python 命令时 Python 脚本的行为。根据发行版或系统配置，python 可能已安装，也可能未安装。如果 python 已安装，其目标解释器可能指向 python2 或 python3。终端用户可能不知道类 Unix 系统之间的这种不一致性。本 PEP 的目标是减少用户对 python 引用什么以及脚本行为的困惑。

本 PEP 的下一节中的建议将概述在以下情况下的行为

• 使用虚拟环境
• 使用 python2 或 python3 的 shebangs 编写跨平台脚本

本 PEP 的目标是澄清脚本终端用户、发行版提供商和脚本维护者/作者的行为。

建议

我们的建议详情如下。我们指出这些建议所基于的任何期望。

本 PEP 的历史

2011 年，大多数发行版将 python 命令别名为 Python 2，但有些开始将其切换到 Python 3 ([5])。由于一些前者发行版默认不提供 python2 命令，因此以前 Python 2 代码（或任何直接调用 Python 2 解释器而不是通过 sys.executable 调用它的代码）无法在所有类 Unix 系统上可靠运行而无需修改，因为 python 命令会在某些系统上调用错误的解释器版本，而 python2 命令则会在其他系统上完全失败。本 PEP 最初提供了一个非常简单的机制来恢复跨平台支持，只需发行版维护者进行最少额外工作。简而言之，建议是

1. 对于与 Python 2 和 3 都兼容的代码，首选 python 命令（因为它在所有系统上都可用，即使那些已经将其别名为 Python 3 的系统）。
2. python 命令应始终调用 Python 2（以防止当 Python 2 代码在 Python 3 上运行时出现难以诊断的错误）。
3. python2 和 python3 命令应可用以明确指定版本。

然而，这些建议隐含地假设 Python 2 将始终可用。随着 Python 2 在 2020 年接近其生命周期结束（PEP 373，PEP 404），发行版正在将 Python 2 作为可选或完全删除。这意味着要么删除 python 命令，要么将其切换为调用 Python 3。一些发行商还决定，忽略 PEP 的原始建议对他们的用户更有利，并允许系统管理员根据其特定环境的需求自由配置其系统。

当前原理

截至 2019 年，在脚本执行前激活 Python 虚拟环境（或其功能等效物）是获得一致的跨平台和跨发行版体验的一种方式。

因此，发布者可以期望软件用户提供合适的执行环境。

本建议的未来变更

此建议将在未来几年内定期审查，并在核心开发团队认为适当时进行更新。作为参考，Python 2.7 系列的定期维护版本将持续到 2020 年 1 月。

迁移说明

本节不包含核心 CPython 开发人员的任何官方建议。它只是一个关于迁移到 Python 3 作为系统默认 Python 版本的各种方面的注意事项集合。希望它们对考虑进行此类更改的任何发行版有所帮助。

• 发行版将 python 命令从 python2 切换到 python3 的主要障碍不是发行版内部的破坏，而是由系统管理员和其他用户开发的私有第三方脚本的破坏。将 python 命令默认更新为调用 python3 表明发行版愿意破坏此类脚本，并可能导致对不熟悉 Python 3 中向后不兼容更改的用户来说相当令人困惑的错误。例如，虽然将 print 从语句更改为内置函数对于自动化转换器来说相对简单，但尝试在 Python 3 中使用 Python 2 符号可能会让不了解此更改的用户感到困惑，从而导致 SyntaxError

  $ python3 -c 'print "Hello, world!"'
    File "<string>", line 1
      print "Hello, world!"
            ^
  SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Hello, world!")?
  

  虽然这对于经验丰富的 Python 爱好者来说可能很明显，但此类脚本甚至可能由根本不熟悉 Python 的人运行。避免破坏此类第三方脚本是本 PEP 过去建议 python 继续指向 python2 的关键原因。

• 错误消息 python: command not found 通常具有令人惊讶的可操作性，即使对于不熟悉 Python 的人也是如此。
• 现代系统上存在 pythonX.X（例如 python3.6）命令，它们调用 Python 解释器的特定次要版本。如果这些实用程序存在，发行版特定的包可以利用它们，因为如果给定主要版本的默认次要版本发生更改，它将防止代码中断。但是，旨在跨平台的脚本不应依赖于这些实用程序的存在，而应在目标主要版本的几个最新次要版本上进行测试，并在必要时弥补次要版本之间存在的微小差异。这避免了系统管理员安装许多非常相似的解释器版本的需要。
• 当发行版提供 pythonX.X 二进制文件时，python2 和 python3 命令应指向其中一个文件，而不是作为单独的二进制文件提供。
• 强烈建议发行版特定的包使用 python3（或 python2），而不是 python，即使是在不打算在其他发行版上运行的代码中也是如此。这将减少发行版以后决定更改 python 命令调用的 Python 解释器版本，或者系统管理员安装自定义 python 命令与发行版默认主要版本不同的情况时出现的问题。
• 如果遵循上述观点并允许系统管理员更改 python 命令，则 python 命令应始终作为指向解释器二进制文件（或指向链接的链接）的链接实现，而不是相反。这样，如果系统管理员确实决定替换已安装的 python 文件，他们可以这样做而不会无意中删除以前安装的二进制文件。
• 即使 Python 2 解释器变得越来越不常见，脚本继续使用 python3 约定而不是仅仅 python 仍然是合理的。
• 如果遵守这些约定，python 命令将仅作为用户便利以交互方式执行，或者在使用虚拟环境或类似机制时执行。

向后兼容性

如果遵循 python2/python3 约定的脚本在不支持这些命令的系统上执行，可能会出现潜在问题。这通常不是问题，因为系统管理员只需创建这些符号链接即可避免进一步的问题。这比尝试使用 Python 3 解释器执行包含 Python 2 特定语法的脚本（反之亦然）时可能出现的有时令人费解的错误更明显。

对 CPython 参考解释器的应用

虽然技术上是一个新功能，但 CPython 2.7 版本的 make install 和 make bininstall 命令已调整为在相关 bin 目录中创建以下符号链接链（链中列出的最后一项是实际安装的二进制文件，前面的项是相对符号链接）

python -> python2 -> python2.7
python-config -> python2-config -> python2.7-config

macOS 二进制安装程序也进行了类似的调整。

此功能首次出现在 CPython 2.7.3 的默认安装过程中。

CPython 3.x 系列中的安装命令已经创建了适当的符号链接。例如，CPython 3.2 创建

python3 -> python3.2
idle3 -> idle3.2
pydoc3 -> pydoc3.2
python3-config -> python3.2-config

CPython 3.3 创建

python3 -> python3.3
idle3 -> idle3.3
pydoc3 -> pydoc3.3
python3-config -> python3.3-config
pysetup3 -> pysetup3.3

这些功能在默认安装程序中的实现进展在跟踪器上作为问题 #12627 ([3]) 进行管理。

对 PYTHON* 环境变量的影响

python 命令的目标选择隐式影响了发行版对各种 Python 相关环境变量的预期解释。在相关 site-packages 文件夹中使用 *.pth 文件、”每用户 site-packages”功能（参见 python -m site）或更灵活的工具（如 virtualenv）都比直接使用 PYTHONPATH 对系统上存在多个 Python 版本更宽容。

排除 MS Windows

本 PEP 故意排除了任何与 Microsoft Windows 相关的提议，因为为 Windows 设计一个等效的解决方案被认为过于复杂，不适合在此处处理。PEP 397 和 python-dev 邮件列表上的相关讨论解决了这个问题。

参考资料

版权

本文档已置于公共领域。