很长时间以来，使 Python 程序在 Unix 上可运行的方法是用 '#!/usr/bin/python' 或有时用 '#!/usr/bin/env python' 启动它们 (然后chmod 它们可执行，当然；这使它们成为脚本)。不幸的是，这对于一般的 Python 程序不再是一个好主意，原因很简单，现在的 Unix 对 Python 的哪个版本是 '/usr/bin/python' 有不同意见。 相反，我们都需要通过使用'/usr/bin/python3'或'/usr/bin/python2'来明确指定我们想要的Python版本（或者让env 明确运行python3或python2）。
在很长一段时间里，即使在Python 3出来之后，在许多环境中（那些你并排安装了Python 2和Python 3的环境），似乎/usr/bin/python仍然是Python 2。我预计在Python 2本身不再被支持后，/usr/bin/python将被废除为Python 2，原因很简单，有很多程序和指令希望它们的'#!/usr/bin/python'或'python'能运行Python 2。改变这意味着什么似乎是合理的破坏，即使它是理论上正确和纯粹的方法。
在现实中，正如我最近发现的，Fedora 31改变了/usr/bin/python的含义，显然Arch Linux几年前也这样做了。在理论上，PEP 394描述了这里的行为，这种行为是PEP可以接受的。实际上，在2019年7月初之前，PEP 394说'python'应该是Python 2，除非用户明确改变了它或者虚拟环境处于活动状态。 然后，好了，有一次修订，基本上是举手之劳，说人们可以对/usr/bin/python（通过）做他们想做的事情。
(这使得PEP 394成为一个文档标准。 就像所有的文档标准一样，它需要描述现实才有用，而现实是/usr/bin/python现在完全不可预测)。
由于Fedora和Arch Linux已经在这方面起了带头作用，其他Linux发行版可能也会跟进。特别是，由于红帽企业版或多或少是基于Fedora的，我不会惊讶地看到RHEL 9的/usr/bin/python是Python 3。我不认为Debian和Ubuntu会如此激进，但如果几年后Ubuntu上的/usr/bin/python至少默认为Python 3，我也不会感到惊讶。(希望Python 2仍然可以作为一个软件包使用。)
