Hacker News Reader

Comment by zenhack | Hacker News Reader

It will probably be a fair bit longer than that before 2.7 stops being relevant. 2.7 is still the default system Python on a lot of Linux distros, which will be in vendor support for longer. It doesn't really matter if the fixes are coming from the PSF or someone else - nice thing about Foss.

RHEL/CentOS 6 is still reasonably widely used, and the system Python there is 2.6.

View on HN

> 2.7 is still the default system Python on a lot of Linux distros

I will never understand why that matters. "ed" is the default system editor, but I'm only "{apt-get,yum} install {vim,emacs}" away from having something I actually want to use. That's the whole point of a distro. You don't have to use Python 2.ancient just because /usr/bin/paleolithic is written with it.

Not all environments have unfettered access to the internet to download whatever arbitrary packages the user decides they need that day. Sometimes you're stuck with whatever the distro shipped with.

I'm not buying that excuse. It implies machines that are installed and deployed exactly once and then never updated in any way, even for security stuff. In that case, an old version of Python would be so far down the list of problems that it wouldn't even be brought up.

Most distros have been shipping Python3 for years, just not set as the target for `/usr/bin/python`. You can run `/usr/bin/python3` currently, almost anywhere.

And "software that has been gradually going EOL for the last 5 years" is not "packages the user decides they need that day". I'd be very surprised if any distros that ship with Python2 do not ship with Python3 in 2020, and I'd even wager that most will default to python3 by then.

What if you have a gigantic Python 2 codebase?

That's a different but unrelated problem. In that situation, consider that official support is almost over for Python 2 and extended support from third party vendors is going to get nothing but more expensive with time. It will be harder to maintain those projects as the dependencies they use drop support for an increasingly obsolete release. It will become much harder to hire great engineers willing to work on legacy versions.

Basically, Python 2 is going to become a very serious technical debt very soon. It's past time to start paying that down.

You've only got 2 years, get started now! If you need to do it gradually (as would be wise for a gigantic codebase), start using `six` to make your codebase forwards-compatible. Then when all your tests pass on python3, cut over, and remove `six`.

(Or take a gamble on Google taking over support for Python2 when it officially goes EOL, I suppose).

Redhat (or someone like them) might keep the lights on for Python 2 if a large enough customer leans on them.

There's approximately zero chance that RedHat will support backports of huge, many-contributor projects like NumPy or Django that are dropping Python 2 support (see: https://docs.scipy.org/doc/numpy/neps/dropping-python2.7-pro... and https://docs.djangoproject.com/en/2.0/releases/2.0/). They just can't - there aren't enough hours in the day.

Five years from how, you don't want to be explaining to your CEO why it's literally impossible for you to integrate with a third party SDK because your stack is so ancient and petrified that new code can't incorporate it.

In this context it doesn't really matter that it's the "default", just that it's supported by the distro maintainers, and so receiving security updates regardless of what the PSF supports.

Reply on news.ycombinator.com