He raised Python like a child, then set it free

Lex Fridman opens with a question sized for a philosophy seminar, not a language-design interview. Van Rossum was born in the Netherlands in 1956; his parents' generation, like Fridman's family from the Soviet Union, had been marked by World War II. Are some people inherently good and others inherently evil, or do we all carry both? Van Rossum did not expect the depth. His answer is plain: we all have good and evil potential in us, and a lot of it depends on circumstances and context.

As a teenager his favorite Dutch author was Willem Frederik Hermans, whose early novels sit in the ambiguous world of resistance against the Germans. You could never tell whether someone was truly in the resistance or a spy, and some characters crossed that line without the reader ever finding out what happened. The main characters are anti-heroes. They fail, at some level, to accomplish their lofty goals. Van Rossum still reads novels. He does not think they touch his technical work directly, even if some people would call language design an art.

The hobbies of his early teens were electronic circuits and mechanical models. For the first years he followed kit instructions without really understanding electronics. He could debug, and he could follow instructions very carefully, a habit that stayed with him. His model of how a transistor works was naive, and he had no real grasp of coils and capacitors. That ignorance became a problem once the digital circuits got complex: the schematic looked fine and the board did not work, because two wires too close together, or a poorly built switch, were throwing megahertz-level oscillations through the whole thing.

At eighteen he went to a Math Olympiad in Eastern Europe with the Dutch team. Another nerdy kid told him about this amazing thing called a computer. He had never heard the word. His own electronics had been simple digital circuits; he thought he somewhat understood a calculator, and he never made the connection. He did not even know that when his parents paid magazine subscriptions with punched cards, a computer was reading those cards and moving money between accounts. He was not interested.

University math changed that. Students could use the machine, which meant typing a program onto punched cards, handing them to an operator, and getting a printout an hour later. The computer was not connected to the real world. You could only write something abstract. Van Rossum did not see a Frankenstein, a word processor, or a game console. He was interested in the tinkering. It is not a complete coincidence, he says, that he ended up creating a programming language, a tool for other programmers. He has always been focused on the activity of programming itself, not so much on what happens with the program you write.

In his second year someone showed him a two-page photocopy of a *Scientific American* column on Conway's Game of Life. He implemented it in Pascal for the batch computer, reading an initial board from input and printing generation after generation. The part he is still proud of is a hardware trick: on paper he designed a logic-gate circuit that took nine bits — a cell and its neighbors — and produced the next value, then translated that circuit into boolean operations on Pascal integers treated as bit strings. About eight instructions could compute sixty bits of a generation. Fridman notes the tell. Van Rossum is proud of the hack, not of the pictures.

The reason was practical. Student computer time was metered; he once got in trouble with a professor for overspending the department's budget. He wanted a larger board and more generations so he could feed in patterns — gliders that reappear translated a cell or two, glider guns — and see what happened. Stephen Wolfram is obsessed with this, Fridman says, because we lack the math to describe the complexity and the only method is to run the system. Van Rossum is not convinced it lends itself to classical mathematical analysis. If you want a real intelligence, maybe you cannot code the agent in Python. Maybe you have to build a universe, then try a lot of rule sets before you find one that does not collapse into trivial repetition.

Popular talk of thinking machines barely touched him. He hardly read science fiction as a teenager, maybe one bundle of stories. He knew how many bits of memory a computer had and how hard it was to program, and he did not believe you could build something intelligent out of that which would satisfy his definition of intelligence. The book that opened his eyes in his early twenties was *Gödel, Escher, Bach*, a book about consciousness.

He totally believes that brains are computers in some sense. The rules they play by are different from what current hardware implements, but he does not believe in a separate thing that infuses us with intelligence or consciousness. "There's no soul." He has been an atheist since about the age of ten, from thinking a bit about math and the universe; his parents were atheists too. You can be an atheist and still insist that intelligence cannot emerge from a fixed set of rules. He is not in that camp.

DNA, in his telling, is a particular machine that encodes an unlimited amount of information in chemical form and figured out how to replicate itself. The structure has not really changed since it originated, hundreds of millions of years ago: like binary hardware whose basic programming language stayed put while the programs written in it developed endless variability. Self-replicating molecules competing for resources, one type eventually taking over, happened before there were fossils. He believes it happened. The gap he could not close as a student was not metaphysical. It was engineering. The computers he could count the bits of were simply too far from a brain.

Consciousness, he is careful to say, is a private topic. Writing programming languages does not go in the direction of developing intelligence. As an avid reader of popular science, though, he does not believe consciousness is all or nothing. A cat, a dog, a mouse has some form of intelligence; a fish does too. Evolution took a long time. He feels that the path toward the human form of intelligence followed the evolution of the senses, especially vision. Interpreting a scene takes an enormous amount of processing, and humans are still better at it than computers.

Mammals developed their levels of consciousness, he suspects, because they are robots with highly developed senses and a lot of rich sensory information coming in. Stack enough of that on top of the basic survival program and something that looks to us like intelligence and self-awareness appears. The place he expects it first is not a philosophical abstraction. When he drives, he does not just follow the rules of the road. He reads the scene: this is a shopping district; an old lady is crossing; someone carrying a pile of mail is heading for a mailbox, so they are going to cross, and he slows down without thinking about it.

That conversion of observation into a model of what another consciousness — or another system in the world — is about to do is everywhere, including the sense that a tree is going to fall. So if anything is going to become conscious, he expects it to be the self-driving car, not the network of a bazillion computers in a Google or Amazon data center. Consciousness, in this framing, is an engineering requirement for interacting with humans: you need to empathize, to understand fear of death, to do basic computation over human desires and flaws. A dog is the existence proof. Dogs have a model of what the humans around them will do. They learn, they get sad, they cry, they are afraid because they were mistreated. We do not assign them much consciousness. He also does not think they have none of it.

Fridman takes the story back to the seventeenth century — Leibniz, Hobbes, Descartes — and the feeling that all thought, all the special things we find in brains, could be converted into logic. Formalize knowledge, then calculate. That is what brains are doing. Van Rossum's objection is specific. Those thinkers had discovered extraordinary mathematics, Newton's calculus among it, and they extended what they could do with logic along those lines. They did not realize that recognizing a face is not a bunch of rules. It is a ton of data plus a circuit that interprets visual clues and context and can massively parallel pattern-match against stored structure.

He has a concrete failure mode. If he sees Fridman tomorrow in front of the Dropbox office, he might recognize him even in a different shirt. If he sees him in a coffee shop in Belmont, or on the beach, he might have no idea. He makes that mistake all the time: a person he only knows as a colleague of his wife's, spotted at the movies, and the face does not connect. Fridman pushes. Every moment you pick up tens of thousands of facts about a scene — black shirt, height, human — and aggregate them. Could that not be encoded and, at the end of the day, calculated?

Van Rossum splits the answer. There is no actual magic. There are enough layers of abstraction, though, from the facts entering his eyes and ears to the understanding of the scene, that he does not think AI has covered enough of that distance. A human body is built of atoms: a uselessly reductionist view. The body is built of organs, organs of cells, cells of proteins, proteins of amino acids, amino acids of atoms, and then quantum mechanics. Each layer is true. You cannot understand a body with quantum mechanics. Knowing we are made of atoms, Fridman adds, is not a reason to get excited yet about recreating organs.

The analogy he trusts is a compiler. The input routine of a parser is, in a sense, a sensing organ. It does not keep a linear sequence of bytes. It builds a mighty complicated internal representation, an abstract syntax tree, uses that structure to produce something relevant — machine code the hardware can execute — and then throws the tree away. When a fish or a fly gets visual impulses, he is sure it also builds some data structure. A fly's brain may have few enough layers that the abstraction is not much more than darker here than there, plus motion, which is why your hand makes it leave. That is already an abstraction for motion.

We have similar machinery, much more complicated. You could not drive a car without an incredibly good abstraction for motion. On top of that we have built more persistent data structures: after some processing, some information is stored in memory and available on recall. Remembering a phone number by repeating ten digits is a fairly conscious form of memorization. Recognizing a face is the other kind. He has no idea how it is done. The brain has specialized hardware for it. He does not know how much of that is coded in DNA and how much is trained over and over between the ages of zero and three.

Everyday life, then, runs at the highest level of abstraction. We are not conscious of the details underneath. Turtles all the way down, Fridman says. Compilers all the way down, van Rossum answers. That is what he was trying to get at. Descartes started a train of thought that said there is no magic, even if Descartes also had to keep soul and body separate, possibly for political reasons. Formalizing human thought continues through Russell, Gödel's incompleteness theorem, and the Turing machine. Van Rossum's version is engineering rather than metaphysics: the stack is real, the magic is not, and most of the stack is still unnamed.

Can programming keep climbing to higher levels of abstraction? Van Rossum thinks that at some point those levels will not be called programming and will not resemble source code. There will still be source code lower down, the way there are still molecules, electrons, and proteins in brains. There will still be programming and system administration keeping the machine running. What the machine *does* sits at a different level. The progress he sees, as a layperson, in facial recognition and self-driving cars has come from endless training data, and the researchers who publish the results do not necessarily know exactly how their algorithms work.

The word *algorithm* is what sets him off. Newspaper fluff about Facebook uses it in a totally different sense from the one he learned at eight or ten: a set of rules you completely understand, that can be mathematically analyzed, that you can prove things about. You can prove that the sieve of Eratosthenes produces all prime numbers and only prime numbers. Fridman introduces Andrej Karpathy's cheeky name for the other thing: Software 2.0, neural nets that learn a mapping from inputs to outputs. You cannot look inside. All you can do is train. Van Rossum would not call that programming. It is a different activity, just as building organs out of cells is not called chemistry.

There is a truism he likes: every task AI has tackled, once we realized how it was done, stopped being called artificial intelligence. A new field of science or engineering took the name away. He may be too focused on terminology, but he expects different concepts, developed by people with different educations and different models of what they are trying to do. The deeper shift is statistical. With nets you can only say that on everything tested it works 99.9 percent of the time, and it fails in unexpected ways you cannot even exemplify. Programming 1.0, he points out, is already there. Most developers abandoned the ideal of a bug-free program long ago. They care about bugs that show up often enough to be annoying, and they take the occasional crash for granted, because there are not enough programmers to make all the code correct and formal methods make the work even more tedious.

The user who clicks a link, gets an error, and clicks again — it often magically works, or they try another path — is running an end-to-end recovery mechanism. Inside systems there are retries, timeouts, and fallbacks. Van Rossum imagines biological systems are even more full of that, or they would not survive. Basic programming education hides the fact. The programs students write are so small that if there is a bug you can always find it. High school and college intro classes are programming in the small. Very few classes teach software engineering, building large systems.

Every summer Dropbox, where this conversation is recorded, takes a large number of interns, as does every tech company on the West Coast. The interns are always amazed. It is the first time in their lives they see what goes on in a really large software development environment. Everything they learned in college was about a much smaller scale, and the difference in scale makes a qualitative difference in how you do things and how you think about them. Did he, in the 1970s and 1980s, imagining Python, picture systems as large as the ones under Google, Facebook, and Dropbox? He was always caught by surprise by pretty much every stage of computing.

He is glad he was not aware of every itch the community had. If you are trying to solve every problem at once, you solve nothing. His problem was focused: a language somewhere between shell scripting and C, a tool that would make him more productive as a programmer in a very specific environment. He gave himself a time budget of about three months, covering both the design — thinking through the syntactic and semantic features — and the implementation, the whole pipeline from parsing source to executing it. He had already taken the good stuff from ABC, the language whose implementation he had worked on, even though he had nothing to do with its design. Not knowing everything he was missing is what saved him.

Fridman spent the 1990s and 2000s doing machine-learning research in C++, while mechanical and electrical colleagues lived in MATLAB. In the last decade the neural-net packages were built on Python, he switched, and he felt a significant boost in getting the job done. He cannot quite put the qualitative difference into words. Then he names it. In C++ he enjoyed writing performant code and building a beautiful structure, especially with newer template standards. He found himself spending most of his time on that structure instead of parsing a file and extracting a few keywords.

Van Rossum still writes C and still writes shell. Most of his things are in Python. Sometimes the task demands another language, and most of the time the task is not "solve X from scratch" but "fix a bug in existing program X" or add a small feature to a large one. Even unconstrained, there is a balance between how long the code takes to write and how long it takes to run. In the phase of exploring solutions you often spend much more time writing than running, because every run shows that the output is not quite what you wanted. Python makes that iteration faster: fewer details to get right before the program compiles and runs, a large library, existing components you can put together and have a prototype going.

It is the electronics hobby again. He used a breadboard: a sprawled-out circuit that would stop working if you shook it, but it functioned, and all he wanted was to see that it worked and move on to the next schematic. Once the design is right you can ask about a PCB, soldering, voltage fluctuations, mechanical disruption. He knows nothing about that in electronics. He knows a lot about it in code. How do you invent the syntax that produces that feeling in three months? He did not. He told himself he did not want to design everything from scratch. He would borrow features from languages he liked. A seventeen-year-old cannot do that, because they have no experience of other languages. He was in his mid-thirties. He had written parsers, implemented ABC, and spent years debating ABC's design with its authors. Indentation and some syntax came from ABC; string literals and how numbers work came from C. Python's good stuff is mostly borrowed.

For three decades van Rossum held the odd, practical title of benevolent dictator for life. Python 3, which broke backward compatibility with Python 2, is the case study Fridman wants. It was a group process. Even as BDFL in name, with everyone respecting his position as creator and owner of the language design, he was looking at everyone else for feedback. Python 3 was sparked by people in the community pointing out a few issues that bite users over and over. Could they do something about those Python warts?

In earlier versions the team had taken backward compatibility very seriously. Many warts had already been resolved because they could be fixed while staying compatible, or along a very gradual path of evolution. What remained were widely recognized problems — not roadblocks, but the same tripwires people hit every time they trip. The team could not think of a backward-compatible way to resolve them. Not resolving them was still an option. For a long time they had resigned themselves to a language that would not be perfect in this way and that way.

Plenty of details are still better in Java, or in R, or in Visual Basic, and they are okay with that: they cannot easily change it, it is not too bad, they can do a little with user education, a static analyzer, or warnings in the parser. Some of the remaining warts were different. Those problems were not going away. They were getting worse in the future. That is when they decided they should do something. Was that the toughest decision in the history of Python as BDFL? Van Rossum does not even let the question land. "The toughest decision was probably to resign."

In July 2018, three months before this recording, he wrote that now that PEP 572 was done he did not ever want to fight so hard for a decision and find that so many people despised it. He wanted to remove himself entirely from the decision process. He would still be around as an ordinary core developer, possibly more available to mentor, but he was giving himself a permanent vacation from being BDFL. He would not appoint a successor. "You all will be on your own." What would they do — create a democracy, anarchy, a dictatorship, a federation? Fridman calls the open-ended gesture almost Shakespearean. Van Rossum is glad he liked the writing. It was written pretty quickly.

PEP 572 was a small feature: assignment expressions, the `:=` walrus operator. Van Rossum had a big hand in its design, though he did not initiate it. After months of going in circles he approved it. A lot of people claimed they knew what was Pythonic, that this would destroy the language, that it violated Python's most fundamental design philosophy. He dismissed that, because he was in favor of it and figured he knew something about that philosophy. He was tired and stressed. On a Wednesday evening he sent the email: accepted, now let's implement it. He went to bed relieved. Thursday morning at 7 a.m. he thought: that was the last debate that is going to be so terrible. That is the last time I let myself be so stressed about a PEP decision. I should just resign.

He had been thinking about retirement for half a decade, joking and telling the community not to take the "for life" part of the title too literally. This was it. He had the day off. He wanted a good time with his wife at a little beach town nearby. In maybe fifteen or twenty minutes he wrote the thing Fridman called Shakespearean. He did not even realize what a monumental decision it was. Five minutes later he saw a link to his own message on Twitter. People were already discussing that Guido had resigned as BDFL. He had posted it on an internal forum he thought only core developers read. He thought he would have at least one day before the news got out.

Fridman plays guitar as a hobby and gets nothing but warmth. As an outside observer of programming communities he often sees camps, and the camps are harsh. Van Rossum does not deny it. Holy wars are a favorite activity in the programming community. If everybody is patting each other on the back and never telling the truth, that would not be good. There is a middle ground: being nasty to each other is not okay, but healthy ongoing criticism and feedback is very productive, at every level. Someone proposes a tiny fix; a reviewer says you can do it better the other way. For the future of the core developer community they already had five or six competing proposals for a constitution. He thinks the debate has been healthy and productive.

He wrote the resignation because he knew Python was in a very good spot. The fifty or a hundred people who write or review most of the code that goes into Python get along very well most of the time. A large number of areas of expertise are represented, different levels of experience in the core, and experience outside it — large systems, small systems, embedded systems. He felt okay resigning because he knew the community could take care of itself. On the grab bag of future topics he is less romantic. He is not that hopeful Python will become a high-concurrency, high-parallelism language. The way it is designed, the way most users use it, and the way it is implemented all make that an unlikely future. Async IO is the special case: overlapping IO, and only IO, which is how you support high-throughput connections. That will evolve. Parallel computing is not what Python is for. You cannot write an algorithm and have a compiler parallelize it. You use NumPy and similar packages, tell them the data and the abstract operation, and then you are back in the C++ world, which is also where TensorFlow takes over across GPUs.

Packaging has always been his least favorite topic. The OS wants to own packaging, but its solution is not specific to a language; Linux has competing cross-language systems, while Node, Ruby, and Python each have ecosystems of their own. His own approach, and most people's, is to install Python with the system packager and third-party Python packages with the Python one. Ten years ago Python packaging was a terrible situation. Nowadays pip is the future. There is a separate Anaconda ecosystem for numerical and scientific Python, and those two can live together. He does not see a need for more than that.

Fridman had watched the five-and-a-half-hour Computer History Museum oral history and came away with the feeling of a life well lived. Outside of family, looking back, what is he proud of? "Python is definitely the best thing I've ever done." He would not say just the creation of Python. He raised it like a baby. He did not just conceive a child; he raised the child, and now he is setting it free in the world, set up to take care of himself. He is very proud of that. Then, as the announcer of *Monty Python's Flying Circus* used to say: and now for something completely different. Van Rossum's favorite bit is the dead parrot sketch. Fridman's too. Pushing up the daisies. It is a good note to walk away on, for a language and for a dictator.