After spreading the news at conferences, on the Python announcement list, and on countless blog posts and books, the Python Software Foundation has finally taken the step to formally announce Python 2 will reach end of life (EOL) on January 1st, 2020.
The message the Python Foundation is trying to make loud and clear is developers should transition to Python 3 as soon as possible without waiting any longer:
We have decided that January 1, 2020, will be the day that we sunset Python 2. That means that we will not improve it anymore after that day, even if someone finds a security problem in it. You should upgrade to Python 3 as soon as you can.
Python 3 was released at the end of 2008, nine years after the inception of the language by its creator, Guido Van Rossum.
From the very beginning, Python 3 was meant to break away from the past, as the only way to fix a number of flaws that affected Python 2 and bring the language evolution forward. Since Python 2 had accumulated multiple ways of accomplishing the same task, one of the guiding principles in the language redesign was making sure there was only one obvious way to do one single task.
While paving the way for the future evolution of the language free of legacy constraints, breaking backward compatibility also significantly slowed down Python 3's adoption. Among the reasons that led developers to not want to transition to Python 3 included: Python 3 sub-par performance vs. Python 2, at least for some years after the initial 3.0 release and until version 3.3 hit the road; initial lack of support for Python 3 among third-party tools and Python libraries (a case of catch-22); and its focus on features that developers did not deem relevant at the beginning.
In spite of these issues, the language grew significantly over the years to include advanced constructs such as generators and coroutines, async/await, concurrent futures, itertools, and more. And while it is true that for some time there was a certain amount of confusion about how to deal with two source-incompatible versions of the language simultaneously, porting Python 2 code to Python 3 is now a much better understood problem, for which great tools exist such as caniusepython3, Futurize, Modernize, and pylint.
All of this contributed to making many organizations postpone indefinitely the transition to a largely more modern and expressive language. Until now, that is, when the Python Foundation is warning them they will be soon on their own, and their only way to get support will be paying for extended support.
The news raised mixed reactions. On the one hand, many developers highlighted how straightforward it was in their case to port their code to Python 3.
Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. There's a library ("six") to help, and in almost all cases you can write 2-and-3 compatible code, which means you can go piece-by-piece.
Even more so, some argue getting ready to move to Python 3 did not require anything more than applying good engineering practices, such as keeping your unit tests in shape and making sure to keep dependencies up-to-date.
If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities. It's not just about Py2/3. Dependency rot is one of the worst forms of technical debt. It often shows broken CI, broken security scanning, lots of generally broken processes that will just keep hurting a team further and further down the line.
Others remarked porting may be easy or feasible in the vast majority of cases, e.g., with Django or Flask-based projects, but there are still many scenarios where porting hits into some kind of stopper, such as an incompatible C extension or an irreplaceable dependency. This is often the case in the computer graphics/visual effects and scientific computing world.
Users and studios are held back because the Python runtime is used inside major applications; Nuke, Houdini, Maya, as well as libraries and APIs. None of them have released a version that runs Python 3 yet. [...] Also, I've worked at a couple studios many people have probably heard of and none of them have unit tests covering much of their code. The focus is on tools that facilitate in-house artists where responsiveness to needs are valued over architecture and completeness.
The entire science stack is "terrible C extensions". This is also the kind of tight-budgeted stuff that needs relatively rare Python/C developers.
Other developers complained that, in spite of all efforts to make the community at large aware of Python 2.7 EOL, Python 2 documentation still offers no hints of that to its viewers.
Contrast this with the PostgreSQL website, which tells me I'm browsing old docs (because Google still offers old links), see e.g. https://www.postgresql.org/docs/9.2/tutorial-window.html
This once again brings into focus the "poor" handling of the transition from Python 2 to Python 3 from its very start.
Other developers contrasted the Python approach to a sounder "don't break the user space" approach, which gives languages and systems written using them a longer life, which is often desirable.
We've got a large amount of FORTRAN code from the '70s that works fine with the latest and greatest FORTRAN compilers (barring deprecation warnings which help guide refactoring efforts). Same with C/C++ from the '80s.
As a final note, it is worth remarking that the Python Foundation announcement does not rule out the possibility of other organizations taking the burden to maintain Python 2.7 and keep it up-to-date. For example, RHEL 7 is based on Python 2.7 and guarantees security/maintenance support till June 2024. The same holds true for Google App Engine and other enterprise service providers.