I thought there won't be any more security updates?

Red Hat, Ubuntu, etc. are going to support Python 2 for the duration of the operating system releases which shipped it. I would assume that Anaconda, et al. will have similar options for paid customers.

Red Hat has committed to keeping Python 2 on life support until 2024 as part of Red Hat Enterprise Linux 8 [1] so you can get security fixes for Python 2 until then if you use CentOS 8.

Canonical will not provide long term support for Python 2 as part of Ubuntu 20.04 LTS. In Ubuntu 20.04, Python 2 is a "universe" package [2] that does not receive updates by Canonical. This means that the you will only get Python 2 security update guarantees with Ubuntu is on 18.04 LTS until April 2023.

Debian is making an active effort [3] to remove Python 2 and packages that depend on it for its next release. It'll likely support Python 2 as part of Debian Buster until 2024.

Note that if you're reading this to delay your move to Python 3 by another few years, you're doing it wrong. This list shows even all slow enterprise-y distros have a deadline for Python 2, not that you can stretch your stuff for a couple of more years :)

[1]: https://access.redhat.com/solutions/4455511

[2]: https://packages.ubuntu.com/focal/python2

[3]: https://wiki.debian.org/Python/2Removal

I believe the biggest thing to worry is your application dependencies, if you also depend on packages that come with your system then probably fine (although I noticed that these are largely ignored even if there bugfixes they don't update them)

Otherwise even if your python has security patches for next 4 years, it won't do you any good when you find a bug in one of your dependencies and bugfix is in a version that's python 3 only

Thank you for providing the extra details — I especially agree with your conclusion: go to your boss and say “even if we pay, we're looking at a drop dead date no later than 2024”.

So? Im sure my non internet facing scripts care

Distro maintainers will be patching security bugs for the foreseeable feature. Do you seriously think if there is a security bug found today Debian maintainers will be like "ah, though luck, I suppose people need to upgrade to py3"?..

Broadly, distros have been ripping out Python2 left and right in advance of 2020. Debian may have a longer support cycle than most and still have Python2 in stable or oldstable.

> Do you seriously think if there is a security bug found today Debian maintainers will be like "ah, though luck, I suppose people need to upgrade to py3"?..

> During DebConf19 we¹ have tried to figure out how to manage Python 2 and PyPy module removal from Debian and below is our proposal. [0]

Debian are in the midst of a large project [1] to remove Python 2 as quickly as they possibly can. Whilst some bugfixes may happen, Debian are already telling you in no uncertain terms:

> port upstream package to python3

> remove any Python 2 use

[0] https://lists.debian.org/debian-python/2019/07/msg00080.html

[1] https://wiki.debian.org/Python/2Removal

Python's open source. Anyone can do security updates. Teams at RedHat, Debian, Oracle, etc, will be doing security updates for many decades I'm sure. You may have to pay.

Can't do it under the "Python" trademark name, though.

A huge amount of the work of distro maintainers is actually just this kind of backporting and applying security fixes. You're right that technically, the python foundation (or whoever owns the trademark) could come after redhat for making these kinds of changes but it's very doubtful they would.

If redhat decided to add new features to python 2.7, I'm sure the PSF would make a stink

You can, that's what RedHat is doing. It will be still Python 2.7.18 + security patches.

You probably confusing it with Tauton (a Python 2.7 with backported Python 3 features) that tried to place itself as Python 2.8. By backporting these changes they created essentially 3rd version of Python that was incompatible with other 2.

Oh no, it’s the whole “IceWeasel” fiasco all over again.

Maybe they could call the new 2.7 interpreter IceSnake.

Ice was used as antonym for fire, thunder and others. Should be some other reference to "Monty Python's Flying Circus" imo.

dead parrot

Not sure that's true?

> As such, stating accurately that software ... is compatible with the Python programming language, or that it contains the Python programming language, is always allowed.

There weren't many before this, either.

3.8 seems to have some new keywords and jazz introduced, so might be better to start with that instead of 3.7 for new projects.

3.8 seems to be much more twitchy about exact versions of dependencies, so I've had problems running the AWS cli stuff on 3.8 at times, because there's no set of non-conflicting dependencies. (oftentimes due to minor/patch level version mismatches)

I keep having issues with 3.8 and many dependencies. Two months back, I started out a new project in 3.8 and two days in was downgrading it due to compatibility problems with Pillow and a couple others.

What typically is happening is that a wheel package was missing. When that happens python tries to compile the package, to do that it requires extra dependencies, such as compiler, python-devel, and other *-devel packages, because they weren't available it failed. This is very common when a new major version is released, it requires authors of the C based packages to build wheels to make installation easier and not requiring extra dependencies.

Looks like Pillow has wheel for 3.8 now since April 2nd, so might work now (no compilation is needed). I don't know other packages so can't check them. Psycopg2 would probably be another one with this issue (also fixed on April 6th).

[1] https://pypi.org/project/Pillow/#files look for cp38 wheel files.

The CentOS base yum repository only has python 3.6.x. I hope they will make later 3.x branches available for installation in the near future.

CentOS / RHEL 8.2 will ship with 3.8.