摘要

此 PEP 概述了当调用 python 命令时 Python 脚本的行为。根据分发或系统配置，python 可能已安装或未安装。如果安装了 python，其目标解释器可能引用 python2 或 python3。最终用户可能没有意识到类 Unix 系统之间这种不一致性。此 PEP 的目标是减少用户对 python 引用内容及其脚本行为的混淆。

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

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

此 PEP 的目标是阐明脚本最终用户、分发提供者以及脚本维护者/作者的行为。

建议

我们的建议在下面详细说明。我们指出这些建议所基于的任何预期。

此 PEP 的历史

在 2011 年，大多数发行版将 python 命令别名为 Python 2，但有些发行版开始将其切换到 Python 3 ([5])。由于一些以前的发行版默认不提供 python2 命令，因此以前没有办法在所有类 Unix 系统上可靠地运行 Python 2 代码（或任何直接通过 sys.executable 而不是通过 sys.executable 调用 Python 2 解释器的代码）而无需修改，因为 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!")?
  

  虽然对于经验丰富的 Pythonista 来说这可能是显而易见的，但此类脚本甚至可能由完全不熟悉 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 文件，“每个用户站点包”功能（见 python -m site）或更灵活的工具（如 virtualenv）都比直接使用 PYTHONPATH 更能容忍系统上存在多个版本的 Python。

排除 MS Windows

此 PEP 故意不包含任何与 Microsoft Windows 相关的提案，因为设计 Windows 的等效解决方案被认为过于复杂，无法在此处理。PEP 397 以及 python-dev 邮件列表中相关讨论解决了这个问题。

参考

版权

本文档已进入公有领域。