
Python 2 Is Dead - miked85
https://www.enricozini.org/blog/2020/python/python-2-is-dead/
======
russellbeattie
16 years after the start of Python 3 and we're still discussing this. I hope
other languages and platforms have paid attention to this transition.

Sometimes one's only purpose in life is to serve as a warning to others...

~~~
reedwolf
Not sure what you mean.

This was the best way to do it. Slowly and painlessly. Any project that
matters is now on 3.

For a bad transition, look at Perl 6, a debacle so big it was renamed Raku and
became a different programming language.

~~~
antoncohen
Python tried to pull a Perl 6 and failed. Python 3 was done as a flag day, a
big breaking change you need to switch over to. Originally Python 3 and Python
2 lacked features that would make it possible to write code that is compatible
with both versions (like `u"foo"` syntax). Slowly they added things to Python
2 and 3 to make it easier to slowly transition.

But it was still full of unnecessary breaking changes.

\- The `print()` function is nice, but they could have left in the `print`
statement for a transitional (deprecation) period. Or left the `print`
statement in, and advise against its use.

\- A lot of the incompatibilities are just stdlib modules being moved around
unnecessarily. They could have made both import paths work for a transitional
(deprecation) period. Or let the old paths continue to work forever, and just
document usage of the new paths.

\- All the new features in Python 3 (async, nice helper functions, etc.) are
compatible with Python 2. They could have added them to Python 2.

The only true breaking change was unicode literal strings. But again, that
could be handled with a slow transitional (deprecation) period. The Python 2
stdlib could have been made compatible with both types of strings (as nearly
all third-party libraries have). And users could have been told to `from
__future__ import unicode_literals` for a transitional (deprecation) period,
to ensure their code is compatible before it becomes the default.

Basically Python 3 could have been a single hard breaking change (unicode
literal strings), with a smooth transition. Instead they decided to make
Python 2 and 3 diverge from each other, making it harder to do the transition.

~~~
mcv
I think next time, when you need to do breaking changes, give it a new name,
so the new thing gets to be hot and new, rather than a problem.

Or do what javascript did: stay compatible with the stupid old way, but build
a brand new language on top of it.

~~~
b2gills
That's exactly what Perl has been doing since 1987.

Where do you think the idea for `"use strict"` in JavaScript came from?

    
    
        use v5.8;
        use strict;
        use warnings;

------
saila
I didn't get the point of this at first (and still kinda don't). I think the
most useful thing might be this link: [https://python-release-
cycle.glitch.me/](https://python-release-cycle.glitch.me/). It's a nice visual
representation of Python version lifetimes, which is useful when deciding
which versions you want to support. I wish they'd put something like that on
python.org.

~~~
zucker42
It's just a gag based off Monty Python. I don't think it's meant to be
anything more.

------
justinsaccount
python2: just works. If you install python2 you get the same stable version
everywhere.

python3: Oh, sorry, you used a feature that was added in 3.x and this system
has 3.(x-1) so now you get SyntaxErrors, or worse, random runtime exceptions.

If you can target a container, buildpack or a specific platform python3 is
fine, but it's been terrible for developers and users since day one. At least,
it's been terrible for me, which is why I still have a pile of stuff to port
to python3.

It's fine for something like go or rust to add new features in a dot release,
where you just need to upgrade your development hosts. Besides, if it compiles
it will work, no surprises later.

But python3 adds new features in 3.5, 3.6, 3.7 and then immediately breaks all
new code on older systems.

Used f-strings? Now your code is broken on 3.5.

A new feature used the walrus operator? Now your code is broken on any system
that doesn't have 3.8 yet.

And 'dead' python2 keeps working.

~~~
chungy
> python2: just works. If you install python2 you get the same stable version
> everywhere.

> python3: Oh, sorry, you used a feature that was added in 3.x and this system
> has 3.(x-1) so now you get SyntaxErrors, or worse, random runtime
> exceptions.

Maybe you were used to Python 2.7 only as "Python 2", but when it was in
active development, major 2.x releases had the exact same thing. I had some
serious troubles when the latest version of RHEL was on 2.4 while the rest of
the world had 2.6 with very large changes. There were all kinds gross hacks
just to make things work on an older, common version.

~~~
userbinator
I think you're making a very similar point to the comment you're replying to
--- that "dead" really means _stability_ ; no more worrying about changes that
make things stop working.

Personally, as a developer who has been working on software for a few decades,
I've gotten increasingly irritated with the growing churn of platforms today
and the astonishing waste of time for everyone who has to deal with it. It's
hard to hit a moving target or build on a shaky foundation, but that's what
the state of software seems to be today. Instead of platforms approaching
stability and spending time on the actual problems at hand, countless
developer hours are wasting solving problems created by others "pulling the
rug out from under them".

I guess the younger generation of developers just hasn't felt enough of that
pain yet, or they're overeager to try new things without thinking of the
consequences. I've always taken the conservative approach and as a result some
of the software I've written has needed little if any new attention in
decades. Some utilities I wrote 25 years ago (not in Python, obviously), I
still use regularly. "It's not the tool, it's how you use it."

~~~
lopmotr
I think it will eventually settle down once people have tried all the ideas
and the needs of programmers have stabilized. Kind of like how bolt threads
were eventually standardized after decades of everyone doing their own thing.
First comes the end of progress, then comes stability. We already have that
with some computer things like basic Linux commands or HTML.

You can always stop now if you want. Download the versions of everything you
need and never change. But you'll miss out on the cool new hotness that you're
wanting everyone else to miss out on if they stop changing too.

~~~
lokedhs
I would believe you if it wasn't for the fact that most things being invented
in software today are new. The industry keeps reinventing things that people
did in the 60's without even doing it properly.

Why doesn't any recent programming languages implement a proper condition
system for example? It's not like working implementations hasn't been around
for decades.

This industry has a severe case of inability to learn from history so I
strongly doubt we'll see things settle down in the near future.

------
at_a_remove
It's still alive where I am. Our eight hundred pound gorilla of its industry
depends on another, lower eight hundred pound gorilla in a _different_
industry, to the point of tying the version we are on (and one that is only
rarely, carefully changed), to a X.Y.Z version of the gorilla below. Upper
gorilla upgrades are expensive, frightful, and slow to come due to the
cautiousness of the industry.

That second, lower gorilla comes with its own 2.Y.Z version of Python
installed and a help page in a large, bold font explicitly forbidding
upgrading that Python 2.Y.Z version, lest some dire things happen. And so in
my little niche of the world, Python 2 Is Alive. I am not holding on out of
stubbornness.

As I learned in a previous job, software lives for a lot longer than expected
or even desired, like some declared extinct species popping up decades later.

------
1337shadow
Best transition ever IMHO: I started Python end of 2008, approx 1 year prior
to Python 3 release, which I started learning at the same time I was learning
Django.

I disregarded Python 3 for a few years, then started accepting pull requests
for Python 3 support on my packages when Django started to support Python 3,
added it to the CI build matrix.

Then, I started to code compatible with Python 2 & 3 while keeping Python 2 as
my main Python (private codebases). A few years later (not so long after Arch
Linux made Python 3 the default) I started using Python 3 as main Python,
contributed to other packages for Python 3 support as I needed it.

It was hard, until I became sufficiently efficient at it, then it became a joy
to have "such easy" contributions to make to the Python ecosystem, note that
at the same time I was doing the same with Django versions which did break
user code often on upgrade.

Perhaps it's because I worked so hard to upgrade codebases during Django 1.x
days, and Python 2 to 3, that every upgrade now seem so easy, anyway, it
basically feels like I have nothing to do anymore given the current state of
the parts of the ecosystem that I depend on.

As of this day, I must admit that the whole operation has been a great
success. I could jump in the train when I felt like it, and nowadays upgrading
has never been easier, asyncio has become really fun to use with Python 3.8,
Django 1.x days were hard on users to upgrade, but since Django 2.0 it's
mostly been a no-op for me, most of my Django 2.x codebases just work on
Django 3.0.

For those who had left Python or Django, or decided not to try it at all, it
really seems to me that now is the best moment than ever to try it out, again
or for the first time. Yes it was pretty hard, yes it took a while, but I
really feel golden about the current situation. I'm glad I sticked with Python
and I see people coming back to it, it's really useful for a wide variety of
use cases.

~~~
millstone
It's not normal to have to write new code to retain compatibility. ES6 was a
huge change, but was sufficiently compatible with ES5 that you didn't need to
double your test matrix. C++11 is another example of a major evolution that
retained backwards compatibility.

There have been other painful upgrades (Swift, Rust) but these have been in
younger languages with less established codebases; both have since shifted to
a mature-language model. Python3 is unique in attempting to aggressively
evolve a very mature language with deep established codebases, and has paid a
heavy price.

~~~
1337shadow
I'm not convinced that spreading the BC breaks over more Python major versions
would have been more helpful or worse ... Hard to say of course, will we ever
know for sure ? It seems to me that the problem would have been multiplied.

------
throwaway3878
Python 2 isn't dead. What they really mean is: "See all those countless
developer-hours spent into adding features, fixing bugs, patching
vulnerabilities for free in a language you use every day to make boatloads of
money without us ever asking anything in return? Well we won't do it anymore.
For free, at least."

~~~
xwdv
If enough people say it’s dead and believe it in their heart, it makes it
true.

Personally it’s long been dead to me.

~~~
serf
> If enough people say it’s dead and believe it in their heart, it makes it
> true.

except for COBOL, which has the Schrodingers' property of having been (called)
dead for 40+ years, but also somehow powering the world and its'
infrastructure.

~~~
drdeadringer
Who besides "government" and related spin-offs such as DoD contractors use
COBOL?

Does "subsidized zombification" count for a programming language being
otherwise dead?

Side Note: 20 years ago a SciFi book introduced me to the idea of "Software
Archaeology". These days, such a term is slowly gaining traction as a job
description. I've had to professionally dabble into this myself from time to
time.

------
bionoid
I came across Tauthon [0] a while back, it seems quite active. I have a
codebase that has proven difficult to port, so this is the backup plan..
"Tauthon is a backwards-compatible fork of the Python 2.7.18 interpreter with
new syntax, builtins, and libraries backported from Python 3.x. [...]"

[0]
[https://github.com/naftaliharris/tauthon](https://github.com/naftaliharris/tauthon)

------
CameronNemo
Software is never alive or dead. And python2 can certainly be found in the
wild. Just yesterday I tried to use buildroot to build an image for my rock64
board. The build failed because a python2 script was executed by a python 3
interpreter.

~~~
erik_seaberg
Every shebang should say python2 or python3. Whatever you want, "python" is
not a reliable way to get it.

~~~
downerending
True. And certainly a python3 script should never, ever assume that 'python'
is python3.

------
meddlepal
Are there any companies out there that might sell supported updates to Python
2 going forward? Seems like a decent business idea considering how much Python
2 is still in the wild.

~~~
throwaway894345
Seems like that would quickly fragment unless the ecosystem consolidates
around one particular vendor or all such vendors consolidate on a standard
fork.

------
carapace
I was planning to host and maintain a fork of Python 2.7 in perpetuity (I was
gonna call it "Bladders" ;-)

It turns out that Pypy will have Python 2 support. I don't know the details
but it sounds like you'll be able to run py2 code using pypy (not pypy3) for N
more years.

------
harikb
Regardless of Python 2 vs 3, what is sad is that every new language, be it Go,
Rust, Swift, Dart, Nim whatever is dividing whatever set of ‘good, smart, and
creative’ engineers we have into smaller group each implementing their own
sorting algorithm in their own language. Just to be clear, I am not counting
myself among them. I am talking about those who design languages, write
runtimes, JITs, stdlibs whatever - people much smarter than us. They do this
in their free time!

I am surprised that even 1,000+ languages (at least 50+ mainstream) haven’t
satisfied all the wishes and itches. May be that is humanities curse! Creative
people constantly want to create a new language and redesign everything while
bigger and better problems remain unsolved.

Python 2 vs 3 just seems like yet another thing that breaks up the creative
talent pool to waste time solving the same problem in two ways.

LLVM is the first thing I have seen that removes at least some of this
duplication. But I hear even Rust is looking at alternate backend! Go doesn’t
even use LLVM, all for good reasons I am sure.

~~~
staticassertion
Are they really divided? Maybe if people only used one language. I would
suspect that almost any Rust, Go, Swift, Dart, and Nim developer today is
proficient in one, probably two other languages, at the least. I doubt that
even 10% of "Rust programmers" are employed to write Rust full time.

What I might agree with is that interoperability is something that should be
considered more going forward. I'm unsure about some of them, but Rust focuses
a lot on interoperability via FFI, Go's FFI story is bad, as far as I know,
Nim's is decent, and I don't knwo about Dart or Swift.

The top languages are all virtually identical. There's so little difference
between, say, Java and Python, despite there being _so much_ difference. So
maybe there are 50 "serious" languages, but they all fall into a few buckets.
There's less meaningful diversity than it seems, I think.

~~~
harikb
Your point about interoperability is probably a better expression about what I
had in mind. Whenever there is a new advance in algorithms, at least all
languages should benefit from the “reference implementation”, be it C-FFI (the
current story - write in C first and everyone wraps) or something like
WebAssembly. Then when a fancier/more idiomatic one is available, use that.
Current story with the C library path is so hard to use in practice.

------
sriram_malhar
Don't make the mistake I did: do not delete python2 from Linux. My python
environment on my Linux box was hopelessly messed up, so I thought I'll delete
all python installations and start afresh. I did not realise how much
Linux(Ubuntu) depends on python2. When I attempted to do an apt install, it
started deleting all kinds of programs in /bin, /usr/bin and so on. The
machine wouldn't boot up. It had to be restored from scratch. But it did
achieve the original objective of having a properly functioning python :)

If someone can explain this dependency of the package management system or the
behavior I saw, I'd be very grateful.

------
madrox
PHP is still used by 78.2% of the internet according to some sources [1]. The
death of any language or version is always greatly exaggerated. Maybe new
projects aren’t being spun up with it, but many old projects never die and
need ongoing maintenance. Until very recently the most recent project I was
working on used python2.

1\. [https://w3techs.com/technologies/details/pl-
php](https://w3techs.com/technologies/details/pl-php)

~~~
zeitg3ist
PHP is one of the few languages that advertises itself by default in server
headers, so I would take that data with a grain of salt.

------
qqssccfftt
Society if Python 3.3 was the first version of Py3k

(picture of utopian society)

------
ivan_ah
Here is a link to the Monty Python sketch where this post takes its lines
from: [https://youtu.be/vnciwwsvNcc?t=154](https://youtu.be/vnciwwsvNcc?t=154)

------
blauditore
I'm wondering, can't existing Python 2 software be automatically converted to
Python 3? It might be ugly at times, but still better then vulnerable...

~~~
Groxx
To join in the other comments here: because it's not safe to do so
automatically. There are semantic changes to the language that do not have
automate-able solutions. E.g. how strings/unicode/bytes work, to name just
one.

------
baud147258
One piece of software (a kind of custom package/build manager) I'm using at
work still runs on Python 2. If it still works, why change it?

~~~
blauditore
Because of potential vulnerabilities due to the lack of patches (in the
future)?

~~~
tsbinz
There will be patches. Ubuntu 18.04 LTS shipped with 2.7 and is supported
until 2023. RHEL 7 shipped with 2.7 and is supported until 2024. What will be
interesting to see is if there will be a "standard" fork that everybody pulls
patches from, or if every vendor patches himself ...

~~~
baud147258
Though it's deployed on Windows...

------
moron4hire
[https://m.youtube.com/watch?v=vK3WhJGg7PM](https://m.youtube.com/watch?v=vK3WhJGg7PM)

------
Bahamut
That page may say that, but I still maintain a ton of Python 2 work stuff that
will never be off of Python 2 while the work ecosystem lives.

------
brnt
Always felt like Python 2 is going the way of Latin, it won't develop anymore,
but it will still be used, in ever fewer niches.

~~~
pjmlp
Actually Latin is still being developed, as official language for Vatican
documents and they have language experts to update the dictionary for modern
terms to keep the language updated.

 _Telephono mobili Android decurrit_

------
dorfsmay
So is OSX going to have python by default now?

~~~
riazrizvi
Do you mean is MacOS going to have Python3x installed by default now?

~~~
ridiculous_fish
Apple has said that Python will be removed from the default macOS install.

~~~
bobbylarrybobby
Looks like only python2 is being removed:

    
    
        $ /usr/bin/python2
        WARNING: Python 2.7 is not recommended.
        This version is included in macOS for compatibility with legacy software.
        Future versions of macOS will not include Python 2.7.
        Instead, it is recommended that you transition to using 'python3' from within Terminal.

~~~
ridiculous_fish
The Catalina release notes do say "Future versions of macOS won’t include
scripting language runtimes by default."

~~~
dorfsmay
Thanks. Sad, especially considering they moved to zsh. Trying to write short
scripts that work both on Linux and Mac is getting more difficult.

~~~
ridiculous_fish
I agree, yet I think it's for the best. Apple has not been a motivated steward
of the Mac Unix layer, so it's best for them to get out of the business
entirely, and make space for the community to converge on a standard package
manager.

------
musicale
Python 2 is not dead. [https://www.pypy.org](https://www.pypy.org)

------
hujun
The first IPv6 RFC(1883) was published back in 1995, 25 years later, IPv6 only
network is still rare.

------
joefourier
What motivated the Python devs to abandon backwards compatibility with Python
3? I don't see any major departures or revolutionary new features
transitioning from 2 to 3. While there's certainly upgrades (e.g. strings),
there's enough small changes that upgrading to 3 is rarely a pleasant
experience.

~~~
macintux
[https://snarky.ca/why-python-3-exists/](https://snarky.ca/why-
python-3-exists/)

~~~
harikb
What that article casually ignores is the fact that there _could have been_ a
Python 2 fix (as Python 3) that took the approach of fixing encoding to utf8
only. If that was the only thing Python 3 vs 2 was breaking, life could have
been so much better.

~~~
mixmastamyk
The go approach was not well known at the time, maybe would have worked. Water
under the bridge.

------
coldtea
Cobol is still alive, so I very much doubt Python 2 will be dead anytime
soon...

~~~
pjmlp
Actually Cobol got its latest ISO revision in 2018, so it is more Python and
less Python 2.

------
seemslegit
It's just resting.

------
brians
What would kill Python 2? RCE in pip?

~~~
saila
The pip docs say support for Python 2.7 will be dropped in January 2021 or if
there are show-stopping bugs in Python 2.7 that affect pip before then:
[https://github.com/pypa/pip/blob/master/docs/html/developmen...](https://github.com/pypa/pip/blob/master/docs/html/development/release-
process.rst#python-2-support)

~~~
banana_giraffe
Does that mean that random things that rebuild or restart and require "pip
install requests" before they start up or whatever will just gleefully break
on Jan 2021?

~~~
saila
I'm guessing you'll get a warning when installing or updating pip on Python
2.7. I know for Python 3.4, pip has been showing a deprecation warning
whenever it's installed for a while now. I assume they'll do the same for 2.7.

So, I suppose the answer to your question is yes--if you blindly update pip
and/or you don't heed those warnings and pin your pip version accordingly.

Edit: I was curious, so I installed the latest Python 2.7 and pip. `pip
install` (or any other pip command) shows a deprecation warning with info
about dropping support for Python 2.7 every time you run it.

------
Aeolun
Python 2 has been zombified!

------
thysultan
Long live the King.

------
TheDesolate0
LOL Try telling that to Mozilla

------
daotoad
Netcraft confirms it.

------
Rochus
knife and fork

------
hexane360
I will not buy this python, eet is scratched.

Do you want to come back to Python 3, bouncy bouncy?

~~~
smitty1e
Sorry, my hovercraft is full of eels.

------
battery_cowboy
Long live python 2!

Edit: this comment is meant to be funny but serious, it's not going anywhere,
I've seen older tech that's still going strong in the "enterprise".

------
mark-r
I was wondering what could be added to the discussion at this late point, and
the answer is - nothing. The page is nothing but a transcription of one of
Monty Python's better bits. I'm sure someone else has done it before, perhaps
better.

