Red Hat Enterprise 8 was released the other day, and now Red Hat
has published an article on Python 2 (and 3) in RHEL 8
The short version is that they aren't providing a package called
'python' but instead two packages called 'python3' and 'python2'
(or two 'application streams'
for Python 2 and 3, which come with additional packages). Although
it's not entirely clear, Red Hat is apparently not going to have a
/usr/bin/python symlink by default, leaving it up you to set one up
through their alternatives system. Red Hat is recommending that you
explicitly use '
python2' or '
python3' as the name of the script
interpreter in '
#!' lines, instead of relying on just the '
(The presence of a '
python2' binary name is not new in RHEL 8;
one was present at least as far back as RHEL 6. Also, this may or
may not backtrack on things Red Hat said a year ago.)
In a way, the big news here is that RHEL 8 includes Python 2 at all as an official package, since RHEL 8 will be supported for probably somewhere around a decade (and they'd previously sort of suggested that they weren't going to). Unless Red Hat officially abandons doing any updates for Python 2 at some point, this means that they'll be supporting it (at least as far as fixing any security issues that are discovered) for much of that decade, and since their work here is open source, other people can take advantage of it. I suspect that Red Hat is not entirely happy with this, but I also suspect that they felt they had no choice for various reasons.
(I rather expect Python 2 to not be included in a future Red Hat Enterprise 9, which might be released somewhere around 2023 or 2024 based on past history. Unless Red Hat gets a lot of push back from customers, I suspect that RHEL 8 will be the only dual-Python RHEL release.)
I suspect that this makes it somewhat more likely than it already was that Ubuntu 20.04 LTS will include Python 2. At the moment, Python 2 is currently part of the bleeding edge Ubuntu rolling version and is still apparently part of the 'main' package repository. That could change before 20.04 LTS freezes and branches, but Ubuntu is running out of time to do that and, more importantly, they're running out of pre-LTS releases to do it in; there would normally only be 19.10, due out in October. Since RHEL 8 includes Python 2, including Python 2 in Ubuntu is safer in that Ubuntu can probably rely on copying Red Hat's fixes, if any are needed.
(Also, per this 2018 LWN article, Debian will be shipping Python 2 with their next distribution, which they're in the process of trying to release at the moment. I believe that Debian wants to strip out Python 2 after that, but I wouldn't necessarily expect fast movement on that, and Ubuntu probably won't be more aggressive than Debian here.)
None of this means that people using Python 2 are completely safe. For a start, Python based packages and systems have been moving away from supporting Python 2 for some time. For an example that's relevant to us, the last Django version that supports Python 2 is 1.11, which itself will only be supported until April 2020 (cf). Unless we want to count on Ubuntu 18.04's packaging of Django (and we don't), the presence of Python 2 in Ubuntu 20.04 will be not too relevant for our Django web application. These days, we also install some popular Python packages for GPU computation and so on, and they're very likely to be Python 3 only soon if they aren't already (I haven't checked the current state of things like Tensorflow). And even if Ubuntu 20.04 includes Python 2, Ubuntu 22.04 might not, and that's not all that far away.
I also suspect that even when Python 2 is available in some form,
more future distributions will follow RHEL 8's model and try not
to provide a
/usr/bin/python that points to it, especially on
completely new installs (which is our usual case). We can try to fight this,
but I suspect that we're better off changing our Python (2) programs
to use '
#!/usr/bin/python2'. Our users may force our hands, though,
if they object strongly enough to there not being a '
(Slowly making that change may give us a chance to inventory just how many Python programs we actually have rattling around this place. The answer is probably 'more than I thought we did', since we've been writing various random things in Python for quite a while now.)