What Python Actually Is
From One Person's Project to a Community Language
In 2008, Python deliberately broke itself.
Python 3.0 changed the language in ways that stopped older programs from running. Every team, every book, every tutorial, and every package maintainer had work to do, and a great many of them did not do it for years. Python 2 and Python 3 lived alongside each other for over a decade.
Three decades, six turning points
| When | What happened | What it changed |
|---|---|---|
| February 1991 | Van Rossum posted Python to USENET, the discussion network people used before the web | It stopped being private. Anyone could download it, complain about it, and send fixes back |
| January 1994 | Python 1.0 | A public marker of something stable enough to build on, by which point the work already reached past its author |
| 2000 and 2001 | Python 2.0, then the Python Software Foundation, a nonprofit that holds Python’s legal rights | A version line that lasted the better part of twenty years, and an organization to carry infrastructure, events, and community |
| December 2008 | Python 3.0 | The break described at the top of this lesson |
| 2018 and 2019 | Van Rossum stepped back in July 2018 after nearly thirty years of final say. The first five-member steering council was elected in early 2019 | Final decisions stopped depending on one person staying available |
| 2020 onward | Support for Python 2.7 ended in January with a last release that April, and new versions settled to one a year | No more fixes for Python 2, and predictable timing for everyone building on Python 3 |
Two of those rows are worth another sentence. The PSF looks after the project rather than the language: it holds the legal rights and pays for the infrastructure, while what actually goes into Python is decided elsewhere. And the steering council is elected fresh after each release that adds features, and prefers agreement and delegation to voting on everything itself.
What a broken language proved
The Python 3 migration is worth an extra look. Eleven years passed between Python 3’s release and the end of support for Python 2, and the cost landed on real teams with real budgets.
I was part of such a team. Moving from Python 2 to Python 3 was real work, and that work had to be prioritized. What I saw in practice: most projects did not get updated but kept existing as Python 2 projects no one wanted to touch. Most of them vanished; they simply became old enough to throw away, or got replaced with something completely new.
That is worth knowing for two opposite reasons. It shows a project willing to accept an enormous bill to clear out accumulated design problems rather than carry them forever. It also shows precisely how expensive that is once people depend on you, which is a large part of why it has not happened again.
Python is open source, meaning its code is available under terms that let people inspect, use, and improve it. That is not the same as unmanaged. Open development still needs review, maintenance, and someone answerable for decisions, and building those is most of what the last three decades were for.
What history cannot tell you
All of this gives you reasons to take Python seriously. It survived a self-inflicted wound, built institutions that outlasted its founder’s authority, and has kept shipping.
It tells you nothing at all about whether Python suits your project. A language can be old, active, well governed, and completely wrong for what you are trying to build.
That is the end of the background. From here we go looking for evidence: the kinds of work Python is actually used for, and what makes it fit them.
Go deeper
Python’s official documentation carries a longer history and licensing timeline, and PEP 13 describes the governance model in force today. A PEP, or Python Enhancement Proposal, is the document format used to propose and record important Python decisions. Both are optional.