
Guido van Rossum: Python 2 end-of-life will be on January 1st, 2020 - bakery2k
https://mail.python.org/pipermail/python-dev/2018-March/152348.html
======
nineteen999
I note RHEL 7.x still contains Python 2 as the default, with Python 3
available from EPEL. But you can't remove Python 2 since just about everything
in the system (including the package manager) depends on the Python 2.

RHEL7 is not due to be EOL until 2024, so Redhat (and others) will be holding
the baby for a long time after 2020.

~~~
jlgaddis
The end of "full support" for RHEL 7 is "~Q4 of 2019".

After that, there's "Maintenance Support" until 30 Jun 2024 but that only
includes "errata", which are "provided at Red Hat's discretion" \-- and
specifically excludes "Software Enhancements" ("additions of new functionality
beyond correcting defects ...").

I expect that after Python 2's EOL, we'll see very little in the way of
updates for RHEL 7's Python 2 packages. There just won't be that much for them
to do.

~~~
nineteen999
It's referred to as Extended Update Support (EUS). Of course nobody is
expecting any enhancements beyond 2019 but for long-lived critical
infrastructure projects (eg. mine) any critical security fixes will be
required - for my project in particular at least until 2022.

------
kbaker
The 'wall of superpowers' looks much better than last time I looked. Almost
all done!

[https://python3wos.appspot.com/](https://python3wos.appspot.com/)

~~~
thinkpad20
That list was a little surprising to me. Simplejson at the top, a library I’ve
never used which seems to be obviated by the presence of json in the standard
library (similarly argparse). Surprised to see pymongo above Flask. Also
surprised to see Django having 10m more downloads than Flask.

~~~
coldtea
> _Simplejson at the top, a library I’ve never used which seems to be obviated
> by the presence of json in the standard library_

json and simplejson are the same modules. It's just that json is based on an
older version of simplejson, since the latter is not tied to the Python
release cycles, and updates faster.

Simplejson also works with older pythons that didn't have json built-in (2.4
etc).

People using it is not about needing a JSON because there isn't one in the
standard library, it's because it was faster than it. 2 times faster loading,
and somewhat faster dumping (depending on json and simplejson version).

>* Also surprised to see Django having 10m more downloads than Flask.*

Django is much older and more established. When Flask was still a new thing,
Django had several versions out and people using it.

~~~
HankB99
Does having the package available for 3.x facilitate code migration? Would the
references to the builtin in 3.x require other code mods (or just the import
statement?)

~~~
coldtea
Not very familiar (mostly using 2.7 atm), but I think simplejson should be a
drop-in replacement to the built-in, and as such shouldn't affect code
migration.

------
mattbillenstein
As a Python2 holdout, I'm glad they extended the EOL -- and I'm actually glad
I held out this long, starting some python3 stuff now and things work -- libs
and tools that I'm used to in python2 seem all there in python3.

~~~
dfee
If you don’t continue to hold out, who will? And, if you move on, are we
losing access to living history?

~~~
oliwarner
Let's maintain every version of everything ever made, forever. Won't somebody
please think of the children!

But if that wasn't sarcasm, nobody's removing "access" to this historical
artefact. Python 2's source code is available as long as somebody stores it.
But the resources required to keep it secure are needed elsewhere. If you
simply want to _preserve_ it, talk to an archivist. The Python community has
moved on.

~~~
dfee
It was sarcasm!

~~~
mattbillenstein
Please use <sarcasm>Something sarcastic</sarcasm> as appropriate ;)

------
Silhouette
I wish we had a better term for this sort of event than "end of life".

It's perfectly reasonable for the team who are the primary developers of
Python 2 to say they want to move on and they aren't going to release any more
updates after some specific date. After all, it's not as if most of us are
paying them for their hard work, appreciated though it is.

On the other hand, it's also not as if Python 2 will suddenly stop working on
1 January 2020. The interpreter on my server will still run, and so will the
scripts that have been using it for many years and have no reason to change
because they're still doing a useful job.

The situation with purely locally-installed software it typically quite
different to the situation with software that depends on some remote service
or runs on someone else's server and is accessed via a web or mobile UI, where
the developers _can_ literally just turn it off and users immediately lose the
ability to run some or all of it. I think we should be more careful about
making this distinction.

~~~
oliwarner
> no reason to change because they're still doing a useful job

Sure, but keeping it compatible with your OS —when it receives updates— is on
you. Backporting security patches from Python 3, 4, 5 etc are on you.

I'll grant you, if you're running an air-gapped machine with no keyboard,
ports or basically any external IO, you probably needn't worry too much about
security. But that would put you in 0.0000000001% of deployments.

Everybody else should treat unmaintained Python 2 interpreters as _dangerous_
zombies that need putting out of their misery. They're potentially vulnerable
to whoknowswhat and past 2020 CPython isn't getting any fixes. If there's any
vector into your system, it's a big fat target, and if vulnerable, a gateway
into the rest the system/network/etc.

Python 2 is on life support. They're pulling the plug on 2020-01-01. You can
choose to keep a zombie lurching around or you can give it a good death.

~~~
Silhouette
This is exactly the kind of overstatement I am challenging here.

Python is a programming language. The Python 2 interpreter has been around for
a long time. We're not talking about some brand new, Internet-facing server
software here. The odds of any sort of critical security issue in the Python 2
interpreter itself are very small, and for anything in the associated
libraries there are plenty of other options if they should ever become
necessary.

This meme that any software that has moved beyond its original publisher's
chosen end date for support is suddenly a threat to all human existence really
needs to die. Aside from being obviously untrue in cases where the software is
open source and available to the wider community to fix or update
independently, security is all about managing risk. If you're going to
consider this a "dangerous zombie", I hope you also aren't waiting up to a
month for your OS developer to release their next bundle of security issues
and then spending further days evaluating them in a lab before deploying them,
and I that you have snapshot-based filesystems with offsite backups taken
every few minutes on all your machines in case some idiot on your network
brings ransomware in on a USB stick without realising. Those surely reflect
far higher risks than continuing to automate with useful, tried-and-tested
Python 2 scripts the same way you have been for the past decade or so.

~~~
oliwarner
Is it an overstatement? Python is handling every bit of IO in your
application. You're at the mercy of the implementation to handle it safely.

You're talking about the odds as if nothing has ever been found wrong in the
stock CPython interpreter. It's certainly low traffic compared to something
like a browser, but there's plenty of bad stuff[1]. That suggests it's pretty
likely there will be more after the 2020 deadline, they just won't get a fix.

I'm also not sure why you're slinging around IT practice (a month is
extraordinary, IMO, but CI testing updates is industry standard around here).
What's wrong with good backups?

[1]:
[https://www.cvedetails.com/product/18230/](https://www.cvedetails.com/product/18230/)

~~~
Silhouette
_Python is handling every bit of IO in your application. You 're at the mercy
of the implementation to handle it safely._

Sure, but that's true of any programming you ever do in any language.

 _It 's certainly low traffic compared to something like a browser, but
there's plenty of bad stuff[1]._

Would _any_ of those vulnerabilities be a concern if you're using Python for
local scripting and automation needs or the like, though?

Obviously if you're running untrusted code or processing data from external
and potentially hostile sources then you may have a different risk assessment,
but Python is used for far more than just things like writing the back ends
for web apps.

 _I 'm also not sure why you're slinging around IT practice (a month is
extraordinary, IMO, but CI testing updates is industry standard around here).
What's wrong with good backups?_

My point was that many organisations already defer installing updates in far
more vulnerable areas, such as their Windows machines, for up to a month
(because Microsoft chooses to bundle them into monthly patch releases barring
the occasional very serious exception) and then typically larger organisations
will test out each update in a lab before deploying it more widely, causing
further delay. In the meantime, that's a month or more that every machine on
the network is potentially vulnerable to whatever exploits might be out there
that the patch will eventually prevent. This is standard practice in Windows-
based environments, and yet the risk involved is surely far higher than anyone
exploiting the Python executable you've kept installed because you have a
decade of useful Python 2 scripts around and don't feel like rewriting them
all because someone declared Python 2 was dead.

Likewise, a large organisation getting hit by ransomware can obviously be
crippling and the best defence is having back-ups as recent as possible so you
can immediately restore any encrypted data. And yet, again, most organisations
don't have that sort of infrastructure in place, and again, this is surely a
much greater risk than having Python 2 around to run all your old Python 2
scripts.

~~~
oliwarner
I will cede that there are non-hostile areas where Python 2 could run forever.
The same sort of environments where FORTRAN have rumbled on forever. And I
agree that there are _other_ hostile environments where some organisations
have completely the wrong priorities. Desktops and networks and traffic
management rarely seem to be perfect.

But on Python, I think many people underappreciate the attack surface. Just
because it's not a server doesn't mean you can't feed it a malformed JPEG, or
funky bytestring that causes it to blow up and spawn shells. It's a similar
problem to PHP in that python includes so many batteries, it's trivial for
attackers to branch out.

And much of this frustration —which leads to the strength of language— is that
we bump into clients and clients' developers who proudly announce they're
running a stack 4 years out of date. It's stupid the number of times I've had
to explain why this is a bad idea. I've even had to demonstrate deep hacks
(with permission, and remuneration) to clients who think they're immune
"because Linux" or whatever. Basically they didn't want to pay their technical
debt until they can see a 12yo Ukrainian (not important) kid could destroy
their whole company.

------
zyx321
Python 2, Windows 7, Adobe Flash.

Early 2020 is shaping up to be a bloodbath.

