红帽企业8号前几天发布了，现在红帽发表了一篇关于RHEL 8中的Python 2（和3）的文章（通过）。 简而言之，他们没有提供一个叫做 "python "的包，而是提供了两个叫做 "python3 "和 "python2 "的包（或者说Python 2和3的两个"应用流"，它们带有附加包）。尽管还不完全清楚，Red Hat显然不会默认有一个/usr/bin/python symlink，而是让你通过他们的替代系统设置一个。红帽公司建议你在 "#!"行中明确使用 "python2"或 "python3"作为脚本解释器的名称，而不是仅仅依靠 "python"的名称。
(在RHEL 8中出现'python2'二进制名称并不是什么新鲜事；至少早在RHEL 6中就有了。另外，这可能是Red Hat一年前所说的，也可能不是。
在某种程度上，最大的新闻是RHEL 8包含了Python 2作为官方软件包，因为RHEL 8将被支持十年左右（而他们之前曾暗示他们不会这样做）。除非Red Hat在某个时候正式放弃对Python 2的更新，这意味着他们将在这十年的大部分时间里支持它（至少在修复任何发现的安全问题方面），而且由于他们的工作是开源的，其他人可以利用它。我怀疑 Red Hat 对此并不完全满意，但我也怀疑他们由于各种原因而感到别无选择。
(我比较期待Python 2不包括在未来的Red Hat Enterprise 9中，根据过去的历史，它可能会在2023或2024年左右发布。除非红帽从客户那里得到大量的反馈，否则我猜想RHEL 8将是唯一的双Python RHEL版本）。
我怀疑这使得Ubuntu 20.04 LTS包含Python 2的可能性比原来更大。目前，Python 2是Ubuntu滚动版本的一部分，而且显然还是 "主 "软件包库的一部分。 这可能会在20.04 LTS冻结和分支之前发生变化，但是Ubuntu已经没有时间这样做了，更重要的是，他们已经没有前LTS版本可以这样做了；通常只有19.10，将在10月发布。由于RHEL 8包括Python 2，在Ubuntu中包括Python 2是比较安全的，因为Ubuntu可能依靠复制Red Hat的修复，如果有需要的话。
(另外，根据2018年LWN的文章，Debian将在他们的下一个发行版中提供Python 2，目前他们正在尝试发布。我相信Debian想在那之后剥离Python 2，但我不一定期望在这方面有快速的进展，而且Ubuntu可能不会比Debian更积极)。
这些都不意味着使用Python 2的人是完全安全的。 首先，基于Python的软件包和系统已经远离对Python 2的支持有一段时间了。举个和我们有关的例子，最后一个支持Python 2的Django版本是1.11，它本身只支持到2020年4月（参见）。除非我们想指望Ubuntu 18.04对Django的打包（我们不指望），否则Ubuntu 20.04中Python 2的存在对我们的Django网络应用没有太大关系。这些天来，我们也安装了一些流行的Python包，用于GPU计算等等，如果它们还不是Python 3的话，很可能很快就会变成Python 3了（我还没有检查过Tensorflow等东西的现状）。即使Ubuntu 20.04包含Python 2，Ubuntu 22.04也可能不包含，而且那也不是那么遥远了。
我还怀疑，即使Python 2以某种形式出现，未来更多的发行版也会效仿RHEL 8的模式，尽量不提供指向它的/usr/bin/python ，特别是在全新的安装中（这是我们通常的情况）。我们可以尝试与之抗争，但我怀疑我们最好将我们的Python(2)程序改为使用'#!/usr/bin/python2'。不过，如果我们的用户强烈反对没有'python'的话，他们可能会强迫我们这样做。
(慢慢地做这个改变可能会给我们一个机会来清点我们到底有多少Python程序在这个地方晃来晃去。答案可能是 "比我想象的要多"，因为我们用Python写各种随机的东西已经有一段时间了）。
