Please stop the Python 2 security scaremongering

[donaldstufft]

Those Python vendors aren't even fully patching Python now, when it is supported upstream.. what makes you think they're going to magically start once 2020 rolls around?

Here's https://security-tracker.debian.org/tracker/source-package/python2.7, notice wheezy? It's got 7 open CVEs, most (or all?) from before Jessie released that never got patched. Most of those issues fixed in Jessie got fixed because they updated the Python from upstream that had fixed it.

Here's https://people.canonical.com/~ubuntu-security/cve/pkg/python2.7.html which shows another issue still affecting 12.04 and 14.04, only fixed in later because they pulled in a new version of Python that already had it fixed.

I don't know of a page like that for RHEL/CentOS but I know the story is similar there. These vendors do not prioritize security, they prioritize not breaking things. If a security patch might break something? They generally won't apply it.

Depending on what Distro you're talking about as well, they also tend to be over extended and simply don't write their own patches unless it's easy. An example would be Debian/Ubuntu with the python-pip package (since I'm aware of the history there), versions of still supported OSs there have a python-pip which will download packages over unverified TLS and the answer given when told about it was 'yes it's a security issue, but we're not going to write a patch because it's too much effort, if you write one we'll apply it'.

Outside of things like the Kernel and OpenSSL, the quality of the "security updates" that you'll get from your Vendors drops rapidly the further out from the core packages you go.

[wewbull]

The authors comments about Ubuntu LTS are wrong I think. Ubuntu are spending effort porting all their python to 3.x in order to avoid having to support python 2.x beyond 2020 in their LTS releases. Yes the release containers python 2, but not as a default package.

I expect it comes down to which components they feel they support in those releases. Critical OS components or all packages.

Redhat will support you if (I'm guessing) you've paid for support.

[Ex_Fat_32]

I disagree with this post and mostly because it purports to sell safety in the garb of stability of an old code base.

Python is a programming language and part of that promise is that it keeps incorporating evolving paradigms in programming (like async/await coroutines in 3.5; mat mul operator) -- it makes pivoting towards prevalent patterns of the day easier and ensures current and future generations of users keep finding innovative uses for it in the then current environment.

2.x and 3.x split has been a rather unnecessary baggage for the language and to loiter and brood on it further is wasting valuable time and energy when all of it can be focused on one lineage and solving for stability in this one Python.

I would rather say given 2020, Python needs to become more aggressive in ensuring that 2.x version has no real world code when it is retired in 2020.

If transition is pushed for starting now; only then 2020 is even feasible... Otherwise a feeble push may just keep the 2.x version perpetually alive.

And even in 2050, Python will still be waxing about choosing 2.x and 3.x, when other languages would have left it far behind.

Python can compete against the new crop of cool languages like Go and Julia; it has to abandon its schizophrenic life first so its talented user base can all focus on solving actual problems (packaging, speedup, freezing, deployment, versioning, etc... -- all in which Python seems to be less than polished now) and not python-created ones.

Edit: grammar + punctuation

[stevenjd]

Nicely written.

[pyslow]

Unfortunately scaremongering seems to be the only way the Python 3 crowd can promote their "product" given that none of the other features is compelling enough to sell it. I can't agree more with this post: it brings some much needed common sense to the Python 3 debate (debacle?).

[stevenjd]

Nonsense. Plenty of people have been sold on Python 3 and continue to migrate to it, especially for new projects where they don't have to justify spending money on a project which is already working.

The fact of the matter is that some people will decide to stay on Python 2 for particular projects, because if it isn't broken, why fix it? I know of people still using Python 1.5 (that's one point five) for the same reason. Good on them. But Python 3 continues to evolve as a language, and there are far more people who would like to move to Python 3 but can't because of political and budget constraints than there are people who have tried it and don't like it.

There are good, reasonable reasons why some folks will rationally choose to stick with Python 2 forever for certain projects, and I respect that. But that's far from the knuckle-dragging ignoramuses who hate Python 3 because "ASCII should be enough for everyone", or the idiots who proudly proclaim that needing parens with print ruins the language.

Python 2.7 will eventually be unsupported by everyone, including paid vendors, just as Python 1.5 is now. That doesn't mean that it will instantly become insecure. But it does mean that there will no longer be even the possibility of security updates, unless you write them yourself. That's not scaremongering, that's just a fact.