The Origins of Python: A Holiday Project Named After a Comedy Troupe

Most popular languages were built to solve a hard technical problem. Python was built to be pleasant to read. Guido van Rossum started it over a holiday break in late 1989^[1], and the decision he made first, that code should look clean and be easy for a human to follow, turned out to be the decision that mattered most. Thirty-five years later it is one of the most widely used languages in the world^[2], and that early bet on readability is why.

A Christmas project at a Dutch research institute

Van Rossum was working at CWI, a national research institute for mathematics and computer science^[3] in the Netherlands. He had worked on a teaching language called ABC^[4], admired parts of it, and was frustrated by others. Over the Christmas break of 1989 he began building a successor, something he could use for system administration tasks that were too big for shell scripts and too small to justify writing in C.

The name has nothing to do with snakes. Van Rossum was a fan of the British comedy troupe Monty Python's Flying Circus, and he wanted a name that was short, slightly irreverent, and memorable. The snake imagery came later, from the community and the publishers, not from the origin. The first public release, version 0.9.0, went out in February 1991.

Readability as a design rule, not a preference

The most visible choice in Python is that it uses indentation to define blocks of code^[5]. Where other languages use curly braces or keywords to mark where a loop or a function begins and ends, Python uses the whitespace you were going to add anyway. This was controversial and remains the first thing newcomers argue about. It also enforces a baseline of readable structure, because the way the code looks and the way it runs can never drift apart.

That philosophy got written down. A longtime contributor, Tim Peters, distilled the language's values into a short set of aphorisms called the Zen of Python^[6], which you can still read by typing import this into a Python prompt. Lines like "Readability counts" and "There should be one, and preferably only one, obvious way to do it" are not jokes. They are the design guardrails that kept the language coherent as it grew.

The painful but necessary split: Python 2 to 3

Python 2.0 arrived in 2000 and became the workhorse version for most of a decade. By the mid-2000s, van Rossum and the core team had a list of early design mistakes they could only fix by breaking backward compatibility, most notably around how the language handled text and Unicode, which matters enormously once your software touches languages other than English.

They made the hard call. Python 3.0, released in 2008, was deliberately not fully compatible with Python 2. The transition was slow and sometimes bitter, because the world had a mountain of working Python 2 code and little incentive to rewrite it. The community eventually got there. Python 2 reached its official end of life on January 1, 2020^[7], and Python 3 is simply Python now. The episode is still studied as a case in how, and how not, to manage a breaking change across a huge ecosystem.

Governance: from benevolent dictator to a council

For most of its life Python had an unusual leadership model. Van Rossum held the title of Benevolent Dictator For Life^[8], which meant he had the final say on language decisions when the community could not reach agreement. It worked because he exercised it with restraint.

In 2018, after a particularly draining debate over a syntax proposal, he stepped down from that role. Rather than appoint a successor, the community moved to a Steering Council^[9], a small elected group that now guides the language through a public proposal process called PEPs, Python Enhancement Proposals^[10]. The transition from a single trusted leader to a durable institution is one reason the language has stayed stable since.

How a clean scripting language took over the web and then machine learning

Python's path to popularity ran through two very different worlds.

The first was the web. Django, released in 2005, gave teams a batteries-included framework for building database-backed sites quickly, with an admin interface, an object-relational mapper, and sensible defaults. Flask offered a lighter, more flexible alternative for people who wanted to assemble their own pieces. More recently FastAPI made it straightforward to build fast, well-documented APIs with modern Python type hints. Instagram, Pinterest, and Spotify all leaned on Python-backed web stacks at scale.

The second world was data and machine learning, and this is where Python's popularity became dominant. Libraries like NumPy and pandas made it a serious tool for numerical work, and then the major machine learning frameworks, TensorFlow and PyTorch, chose Python as their primary interface. When the AI boom arrived, the default language for building and training models was already Python, which pulled an enormous new population of users into the language. The glue between fast compiled code underneath and a readable scripting layer on top turned out to be exactly what researchers wanted.

The honest trade-offs

Python is not fast in the way C or Rust are fast. The standard implementation, CPython, runs code through an interpreter, and a long-standing design detail called the Global Interpreter Lock limits how much true parallelism you get from threads within a single process. The community has worked on both of these for years, with real speed gains in recent releases and active work on loosening the lock. In practice, most Python programs spend their time waiting on a network or a database, or they hand the heavy computation to a compiled library, so the raw interpreter speed matters less than you would expect. Readability and the depth of the library ecosystem usually win the trade.

What it means today

Python runs web back ends, automation scripts, data pipelines, scientific computing, and the overwhelming majority of machine learning work. It is a common first language in universities and a common last language for senior engineers who just want to get something done. The thread connecting all of that is the decision van Rossum made over a holiday break in 1989: optimize for the person reading the code, not the machine running it. That is an unglamorous principle, and it quietly made Python one of the most important tools in software.