A Language for Christmas

Amsterdam, December 1989.

CWI is closed for the holidays. A bored researcher needs a hobby project. What he starts over Christmas will carry the most consequential lock in programming history — added without a fight.

▼

The World

Before Python there was ABC — a teaching language built at CWI in Amsterdam, designed to be readable above all else. Everything about it was tuned for a beginner’s eyes. Where most languages of the era marked blocks of code with braces and semicolons — punctuation the machine needed but the human tripped over — ABC used indentation: the visual shape of the program was its structure. Where C made you juggle pointers and memory addresses, ABC gave you high-level types — numbers, text, lists — that worked the way a student would guess they should.

ABC is where Python’s DNA comes from. And ABC failed.

It failed for a reason worth sitting with, because it explains nearly everything Python did next. ABC was a closed ecosystem. There was no extensibility — no way to bolt on a feature the designers hadn’t anticipated. There was no way to open a file, no input/output escape hatches to the operating system around it. You could write a beautiful program in ABC, and it could not touch anything in the real world. A beautiful classroom with the doors locked.

Outside that classroom, late-eighties computing had its own problems. At CWI, the Amoeba project — an ambitious attempt to build a distributed operating system, one that spread itself across many machines — needed a scripting language: something quick and forgiving for wiring the system’s pieces together. And everywhere Unix ran, working programmers faced the same daily choice. The shell was quick but shapeless — fine for five lines, a liability at fifty. C was powerful but slow to write, and it punished every mistake with a crash. Between those two poles there was a gap the width of most real work.

Into that gap, Perl was already moving, on its way to becoming the sysadmin’s lingua franca — the default answer for anyone gluing Unix systems together. The Perl rivalry would define Python’s first decade.

The Pressure

Every episode of this story starts with pressure, and here the pressure was mundane. The niche was glue: Unix automation, text munging, sysadmin work. The jobs were unglamorous — rename these thousand files, parse this log, stitch these programs together — and they wanted a tool easier than C and more structured than shell or Perl. Nobody was asking for elegance. They were asking to get things done without segfaults.

Notice what’s missing from that list. Nobody in 1989 asked for a language for scientists, or for web servers, or for artificial intelligence. Those pressures hadn’t arrived yet. When they did, in later episodes, the language would bend to meet them — and the bends are still visible in the code you write today. That’s the running thesis of this site: language features are lagging indicators of industry pressure.

The teaching mission — ABC’s unfinished business — never left, either. It stayed folded into the language’s design instincts for a decade, and in 1999 it became explicit, in a DARPA proposal titled “Computer Programming for Everybody”: the idea that programming literacy belonged to everyone, the way reading and writing do, with Python as the vehicle.

The Response

In February 1991, Guido posted Python 0.9.0 to alt.sources — a Usenet newsgroup, which is how software traveled before websites: you published your source code to a worldwide bulletin board and strangers downloaded it, compiled it, and wrote back. The name came from Monty Python, not the snake.

The design answered both of its parents at once. From ABC, Python kept the readability: indentation as structure, high-level types, code you could read aloud. From the Unix world, it took the lesson of ABC’s death: the doors would stay open. Python could open files. It could call the operating system. Crucially, it could be extended — you could wire in new capabilities and reach anything C could reach. Hold that thought about C extensions; it becomes the hinge of this entire documentary.

In 1992, threads arrived — and with them, the lock.

Here is the mechanism, because you cannot understand the next thirty years without it. Python manages memory by reference counting: every object carries a small counter of how many things are currently pointing at it. Bind a new name to an object, the counter ticks up; drop a reference, it ticks down; hit zero, the memory is freed. It’s simple and immediate — and it is not thread-safe. Threads are multiple streams of execution sharing one program’s memory, and if two threads adjust the same counter at the same moment, an increment can simply vanish. An object still in use gets freed. The interpreter crashes, or worse, corrupts data silently.

The standard cure is a lock — a turnstile that admits one thread at a time to whatever it protects. Guido reached for the simplest possible version: one single lock around the entire interpreter. To run any Python code at all, a thread must hold it. This is the Global Interpreter Lock — the GIL — and it means that no matter how many threads a Python program spins up, only one of them executes Python at any given instant.

Understand the moment before judging it. In 1992, every machine had one core: only one thread could physically run at a time anyway. And clock speeds were doubling every eighteen months — if your program was slow, the next chip would fix it. One big lock was simple, correct, and cost nothing you could measure. The GIL was the right call. It went in without a fight. Remember that, because every later attempt to take it out would be a war.

Python 1.0 shipped in January 1994. Functional programming arrived by patch, not by design: lambda, map, filter, and reduce were contributed, as Guido later put it, “courtesy of (I believe) a Lisp hacker who missed them and submitted working patches.” A language open to contributions is open to features its designer never wanted — and Guido’s decade of ambivalence about those features starts here. It pays off later, in the comprehension chapters of this story.

Through the 1.5 era the language grew packages and refined its classes, and something less tangible grew alongside it. On comp.lang.python — the Usenet group where the community lived, arguing in public, in plain text, every thread archived — a culture took shape. Part of that culture was a philosophy that would get a name: batteries included, the conviction that a language should ship with a standard library rich enough for real work straight out of the box. And on June 4, 1999, Tim Peters posted “The Python Way” to the list — the aphorisms that would become the Zen of Python, canonized as PEP 20 five years later. The culture had written down its creed.

The Fight

The GIL’s first challenger arrived before most people knew the lock existed. In 1996, Greg Stein produced a set of free-threading patches against Python 1.4: the GIL removed, replaced with fine-grained locks — instead of one turnstile around the whole interpreter, many small ones around each shared structure, so threads could genuinely run in parallel. They worked.

But fine-grained locking has a price, and it lands in a cruel place. Those many small locks must be taken and released constantly, on the hot path of ordinary operations — and every program pays that toll, including the vast majority that never use a second thread. The cost, in Guido’s later recollection: the patches “slowed down single-threaded execution nearly two-fold.” And when David Beazley exhumed the patch set in 2011 and actually measured it, he found it four to seven times slower.

Guido’s response set the bar that would hold for two decades: no GIL removal that regresses single-threaded performance. Simple to state, brutal to satisfy — because the GIL’s whole virtue is that one big lock is nearly free, and anything subtler starts by paying rent everywhere.

This is the first of four GIL-removal attempts this site tracks: Stein, then the Gilectomy, then nogil, then the free-threaded builds. Keep count as you go. In 1996 the bar was set and nobody could clear it — and nobody much cared, because every machine still had one core. The day machines grew a second one, this quiet engineering trade-off would become the most argued-about lock in software. That day is Episode 3.

Why Your Code Looks Like This

Why is indentation syntax? Because ABC did it, and ABC was right about readability even while being wrong about everything else. Most languages let indentation and braces drift apart, so the shape you read can lie about the structure the machine executes. Python made the shape the truth. You’ve been living with a Dutch teaching experiment from the 1980s every time you hit Tab.

Why is self explicit? Same inheritance — the teaching-language instinct that nothing should happen invisibly. When you read a method, every name comes from somewhere you can see.

Why does lambda feel bolted on? Because it literally was. It arrived in a patch, from someone else, into a language whose designer never fully wanted it — and it still carries the shape of that history, a one-expression guest in a language of indented blocks.

And the GIL — the fossil this episode plants — isn’t in your syntax at all. It’s in your assumptions: in why threads in Python don’t do what threads do elsewhere. In 1992 it was invisible and correct. Keep watching.

Sources

• Guido van Rossum, “A Brief Timeline of Python”
• Guido van Rossum, “The fate of reduce() in Python 3000” (Artima, 2005) — the “Lisp hacker” line
• Greg Stein’s free-threading README, python.org FTP (1996, archived copy)
• Guido van Rossum on GIL removal (Artima, 2007)
• David Beazley, “An Inside Look at the GIL Removal Patch of Lore” (2011)
• “Computer Programming for Everybody” — revised proposal to DARPA, August 1999
• Tim Peters, “The Python Way” (comp.lang.python, June 4, 1999)
• PEP 20 — The Zen of Python