Q&A with Guido van Rossum, Inventor of Python
Microsoft Reactor
AI-assisted summary of Q&A with Guido van Rossum, Inventor of Python — original source. Check the original for full context.
Source published:
Key ideas
- Guido van Rossum joined Microsoft as a Distinguished Engineer to lead a dedicated performance team alongside Mark Shannon and Eric Snow, aiming to deliver substantial speed improvements starting in Python 3.11. (43:36)
- The Python core team has largely abandoned the concept of a disruptive 'Python 4.0' release, committing instead to an annual release cadence (3.10, 3.11, etc.) after the challenging multi-year Python 2 to 3 migration. (47:03)
- Rather than attempting full GIL removal across the interpreter, core development efforts are focusing on isolated sub-interpreters with per-interpreter GILs within a single operating system process. (49:37)
- Browser and mobile environments remain structurally ill-suited for standard CPython due to 30 years of desktop/server architectural baggage, battery constraints, and synchronous execution assumptions. (18:56)
Detailed notes
## Background Published by Microsoft Reactor on YouTube on May 14, 2021, this Q&A session features Python creator Guido van Rossum. According to the page description, the event covers how PyCon was born and Guido's journey as the language's former "Benevolent Dictator for Life" (BDFL) through an open community Ask Me Anything.
## TL;DR Guido van Rossum reflects on the early history of Python, from its origins at CWI as an alternative to C and shell scripts to its unexpected rise as the premier language for artificial intelligence and data science. He explains key language design choices, including functional programming features, typing influences from TypeScript, and the painful lessons learned from the Python 2 to 3 transition. Guido also discusses modern runtime challenges across web and mobile platforms, clarifying why a disruptive "Python 4" is unlikely and detailing his new work at Microsoft alongside Mark Shannon and Eric Snow to speed up CPython starting in Python 3.11.
## Atmosphere & style The session feels warm, unpretentious, and reflective, driven by Guido's candid modesty and dry humor. Rather than adopting the persona of an untouchable software pioneer, Guido speaks like a pragmatic veteran engineer who openly acknowledges past miscalculations, accidental successes, and community disagreements. The conversational exchange with the host flows naturally from technical deep dives into interpreter architecture to relaxed personal anecdotes about his family, cycling, and pop culture tastes.
## Bulletin - [43:36](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2616s) Guido van Rossum joined Microsoft as a Distinguished Engineer to lead a dedicated performance team alongside Mark Shannon and Eric Snow, aiming to deliver substantial speed improvements starting in Python 3.11. - [47:03](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2823s) The Python core team has largely abandoned the concept of a disruptive 'Python 4.0' release, committing instead to an annual release cadence (3.10, 3.11, etc.) after the challenging multi-year Python 2 to 3 migration. - [49:37](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2977s) Rather than attempting full GIL removal across the interpreter, core development efforts are focusing on isolated sub-interpreters with per-interpreter GILs within a single operating system process. - [18:56](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1136s) Browser and mobile environments remain structurally ill-suited for standard CPython due to 30 years of desktop/server architectural baggage, battery constraints, and synchronous execution assumptions.
## Key takeaways - [01:28](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=88s) Python originated over a Christmas holiday at CWI as a high-level scripting alternative to C and shell scripts for the Amoeba distributed operating system, heavily influenced by the lessons of ABC. - [07:37](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=457s) Python's eventual dominance in AI and machine learning was completely unforeseen, as the language was created during an 'AI winter' when artificial intelligence research was widely regarded as stagnant. - [09:26](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=566s) Functional constructs like lambda, map, and filter were early community additions, while reduce was intentionally removed from built-ins due to poor readability in favor of list comprehensions. - [13:05](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=785s) Running CPython in web browsers faces structural hurdles; browser sandboxes lack synchronous blocking I/O, while WebAssembly ports produce impractically large bundles compared to server-hosted setups. - [18:56](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1136s) Mobile platforms clash with CPython's architecture because of high battery and memory usage, as well as OS differences like Android blocking fork(), suggesting a need for lighter runtimes. - [26:49](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1609s) Python's typing Special Interest Group regularly consults TypeScript's typing design decisions and real-world outcomes when evolving Python's optional static type system. - [29:21](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1761s) The protracted friction of the Python 2 to 3 migration stemmed from core developers underestimating how deeply embedded Python had become in enterprise workflows and non-specialist automation. - [32:39](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1959s) Virtual environments remain essential for isolating project dependencies, though complex machine learning stacks still run unavoidable risks of transitive dependency conflicts. - [34:43](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2083s) The name 'Python' was chosen in 1989 as a nod to Monty Python's Flying Circus, CWI lab naming traditions, and a deliberate rejection of classical naming conventions like Pascal or Ada. - [38:37](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2317s) Guido ended his brief retirement during the COVID-19 pandemic out of boredom, choosing to focus his engineering efforts at Microsoft on core interpreter performance rather than machine learning. - [43:36](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2616s) Microsoft's Faster CPython initiative targets iterative runtime speed improvements, aligning with broader industry performance projects from Meta, Piston, and Pyjion. - [49:37](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2977s) A breaking C API overhaul would be the only realistic technical justification for a Python 4.0, but maintainers strongly favor backward-compatible deprecation cycles to avoid disrupting core packages like NumPy.
## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=0s) Introduction and Guido van Rossum's Journey
Dion opens the Microsoft Reactor session by welcoming attendees to the Q&A with Python's creator, directing viewers to check in online using event ID 13426, submit questions in the live chat, and look out for future community meetups. She then hands the floor to Francesca, who introduces Guido van Rossum. Francesca highlights Guido’s educational background in the Netherlands, where he received a master's degree in mathematics and computer science from the University of Amsterdam before creating Python. She traces his subsequent career trajectory to the United States, including his stints at Google starting in 2005, Dropbox in 2013, and his current role as a Distinguished Engineer at Microsoft.
- **Check-in Details:** Hosted via `aka.ms/reactorcheckin` under event ID `13426`. - **Career Highlights:** Master's degree from the University of Amsterdam; worked at Google (2005), Dropbox (2013), and Microsoft (Distinguished Engineer).
---
[01:28](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=88s) The Origins of Python: From ABC and Amoeba to Usenet
When asked how and why Python began as a side project, Guido jokingly wonders how much time they have before diving into his early days at Centrum Wiskunde & Informatica (CWI) in the Netherlands. His first major project there lasted three and a half years, focusing on implementing a programming language called ABC. While ABC boasted a clean, elegant design and taught him an immense amount, it was a commercial failure. The lab had no viable distribution channels or promotion strategies, leading to the project’s cancellation. Guido moved on to Amoeba, a research-oriented distributed operating system featuring a microkernel built by PhD students. As an application programmer tasked with building practical tools—such as backup utilities and mail readers—Guido felt trapped between writing slow, laborious low-level code in C or hacking brittle shell scripts together.
Remembering the elegance of ABC, Guido realized how much easier his life would be if he had a high-level language available for Amoeba. An ideal opportunity arose when his project lead left for a sabbatical in Silicon Valley, leaving the programming team largely unsupervised. As Guido playfully admitted: “I had no social life, so I decided over the Christmas holidays actually that it would probably take me about three months to design and implement a new programming language based on many of the ideas from ABC but also ideas I had myself and I had certain some criticism on parts of ABC.” He rationalized to himself that after those initial three months, team productivity would skyrocket to make up for lost time, though he conceded this was mostly an excuse to avoid cranking out boring backup tools. Within three months, he had a demoable prototype. Roughly a year later, after seeing colleagues and summer interns successfully build tools with it, they released Python to the world via Usenet. Guido's inbox was immediately inundated with fan mail, bug reports, and patches, marking an overnight open-source success.
```mermaid flowchart TD accTitle: Origin of Python accDescr: Progression from the ABC language failure to the Amoeba project and Python's release on Usenet.
subgraph Background ["CWI Background"] ABC["ABC Language Project<br/>(Flopped; lacked distribution)"] Amoeba["Amoeba Distributed OS<br/>(Needed utilities & tools)"] end
subgraph Implementation ["Birth of Python"] Dilemma["Stuck choosing between<br/>tedious C or brittle shell scripts"] Vacation["Lead on sabbatical + Christmas break:<br/>3-month prototype goal"] Demo["Working demo prototype &<br/>internal adoption by interns"] end
subgraph Launch ["Open Source Launch"] Usenet["Published to Usenet"] Community["Inbox filled with fan mail,<br/>bug reports, and patches"] end
ABC -.->|"Influenced design of"| Vacation Amoeba --> Dilemma Dilemma --> Vacation Vacation --> Demo Demo --> Usenet Usenet --> Community ```
- **Early Influences:** Built upon ABC’s ergonomics while addressing its flaws and limitations. - **Amoeba Development Environment:** Constrained by only having a C compiler, which made writing everyday utilities exhausting. - **Timeline:** Conceived over the Christmas holidays; working prototype completed in three months; released onto Usenet after about a year of internal use.
---
[07:37](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=457s) Unforeseen Dominance in AI and Machine Learning
Francesca asks whether Guido ever foresaw Python becoming the dominant lingua franca of the artificial intelligence and machine learning ecosystems. Guido reacts with immediate astonishment, explaining that around 1990, the field was mired in a severe "AI winter." At the time, AI carried a tarnished reputation because decades of grand promises from the 1960s and 1970s had failed to materialize, leading the broader computing community to view artificial intelligence as practically dead or centuries away from reality.
He explains that Python was never aimed at sci-fi applications back then, but rather designed strictly as a practical everyday utility for serious developers who were tired of the extremes of C, C++, and shell scripts. As Guido recalled: “And so everybody thought that that was a dead field that we wouldn't get to any of that science fiction for another century or so.” The language's eventual explosion across modern deep learning libraries and data science ecosystems was completely unexpected from its original vantage point.
- **Historical Context (circa 1990):** Industry-wide skepticism toward AI following unfulfilled promises from the 1960s and 1970s. - **Intended Target Audience:** General software engineers seeking higher productivity than C/C++ without the limitations of shell scripting.
---
[09:26](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=566s) Functional Programming: Lambdas, the Demise of Reduce, and Comprehensions
Addressing an audience question about his past writings on Python’s functional features, Guido reflects on how tools like `lambda`, `map`, `filter`, and `reduce` made their way into the runtime during the mid-1990s. At that stage, he had only surface-level exposure to academic talks on functional programming and had never actively written functional code. In the language's formative period, community contributions were accepted much more casually: if a contributed pull request looked neat and felt acceptable after a few moments of contemplation, he would simply merge it and cut a release.
Guido notes that while `lambda` found great success despite its intentionally restricted syntax, it caused frequent semantic misunderstandings in the community. He recalls almost getting into a drunken shouting match with an engineer who incorrectly insisted that only `lambda` expressions possessed closure semantics while standard nested functions did not. Turning to built-in functions, Guido explains that while `map` and `filter` were intuitive, `reduce` consistently made code difficult to read and comprehend, prompting him to eventually strip it from the built-in namespace. Noting persistent community complaints, Guido bluntly defended his prerogative as creator: “There are still people on Hacker News who are mad at me for that. But eh, it's my language, not theirs; you can design your own language.”
The eventual replacement came when Tim Peters suggested list comprehensions, a construct Guido immediately appreciated because its syntax mirrored standard mathematical set notation learned in school (e.g., $\{x \mid x > 5\}$). This design later expanded naturally from list comprehensions into generator expressions, followed by set and dictionary comprehensions contributed by Barry Warsaw.
- **Functional Additions:** `lambda`, `map`, `filter`, and `reduce` arrived via community mail submissions during the early-to-mid 1990s. - **Removal of `reduce`:** Excluded from standard built-ins because it produced unreadable code, provoking ongoing gripes on forums like Hacker News. - **Comprehension Lineage:** Suggested by Tim Peters based on mathematical set-builder notation; later broadened into generator expressions as well as set and dictionary comprehensions (championed by Barry Warsaw).
[13:05](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=785s) Python on the Web: Backend Dominance vs. Browser Limitations
When asked about Python’s place in web and mobile app development, Guido notes that these are two fundamentally different questions. Web development splits cleanly into front end and back end (though back-end developers often contend with a multi-layered stack that has its own internal fronts and backs). On the server side, Python has long been a powerhouse: Guido worked on Python-based systems during his time at Google, and Dropbox built its entire back-end server architecture in Python.
```mermaid flowchart TD accTitle: Python in Web Development accDescr: Shows Python dominating the server backend while encountering severe constraints inside the browser frontend.
subgraph Backend["Web Server / Backend"] BE["Python Stack"] -->|"Production Proven"| DB["Dropbox & Google Services"] end
subgraph Frontend["Web Browser / Client"] JS["JavaScript Engine"] WAS["WebAssembly / CPython"] -.->|"Large payloads & slow startup"| JS Trans["Transpilers (e.g. Brython)"] -.->|"Limited IO / no browser vendor buy-in"| JS end ```
By contrast, the browser frontend is strictly the domain of JavaScript: unless code compiles or translates into JavaScript, it simply cannot execute there. Guido recalls early mid-1990s efforts (around 1995 or 1996) involving browser applets and dynamic extensions. A browser could dynamically load an extension that opened a fixed-size square box on screen where an embedded language like Python could draw. However, users were required to download and install extensions before visiting a webpage, which caused constant failures and user resistance:
> “Plus, most users weren't so keen on downloading and installing stuff before they could sort of run a website that they were planning to visit for about 5 seconds.”
Java pursued the same applet route and failed just as definitively. Modern efforts to run Python in the browser generally adopt two approaches:
- **Transpilers / JS interpreters:** Tools like Brython transpile Python to JavaScript or implement a Python interpreter in JavaScript. While functional, they receive zero direct support from browser vendors, are alienated from typical Python community practices, and must navigate browser constraints where synchronous blocking I/O (such as opening and reading a local file) does not exist. - **WebAssembly (WASM):** Developers have executed heroic efforts using experimental GCC backends to compile all of CPython and the scientific computing stack (NumPy, SciPy) to WebAssembly. Although WebAssembly is technically impressive, the resulting bundles are huge downloads that still fall short of the functionality and performance of running a Jupyter notebook locally or hosting it on a remote server with a proper web UI.
Guido concludes that Python should stick to its core strengths rather than forcing itself into the browser, pointing out that nobody demands Rust run natively as an interactive browser UI language. Java gave up on the browser without dying, and Python can comfortably focus on server-side web development and scientific data pipelines wrapping libraries like TensorFlow, PyTorch, and NumPy.
[18:56](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1136s) The Mobile App Conundrum: Battery, Memory, and OS Mismatches
Mobile app development remains a much more frustrating, unresolved topic for Python. Guido admits that while it would be fantastic to write native mobile apps in Python, the core implementation has three decades of architectural baggage:
> “CPython is sort of has 30 years of history where it's being built for for an environment that is a workstation, a desktop or a server and sort of it it it expects that kind of environment and the users also expect that kind of environment.”
When developers cross-compile CPython for iOS or Android tablets, it quickly clashes with mobile hardware constraints:
- **Resource & Battery Drain:** CPython is comparatively bloated and heavy for mobile operating systems, rapidly depleting device battery and exhausting memory. - **Educational Drawbacks:** In developing countries, budget phones or tablets paired with external keyboards often serve as the sole computational device for students learning to code. Running full-fledged CPython on these underpowered devices is far from seamless. - **OS Kernel Quirks:** Android presents itself as a Linux environment, yet it prohibits calling `fork()`. As a result, standard libraries like `multiprocessing`—which assume any Linux platform can safely fork child processes—break down completely unless custom mobile process-spawning workarounds are engineered.
Because retrofitting desktop CPython into mobile sandboxes is so clumsy, Guido speculates that the ideal path forward for mobile Python might be adapting a lighter runtime like MicroPython, or creating an intermediate "medium Python"—an engine designed to utilize a proper operating system and moderate memory pools without demanding the full desktop legacy of CPython.
[22:29](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1349s) Perspective on Newer Languages: Rust, Go, Julia, and TypeScript
Guido shares his general enthusiasm for language design, noting that while he loves reading language tutorials, he rarely builds major projects in new languages because reaching for Python is always faster. Examining modern programming languages, he highlights their varying strengths:
- **Rust:** Guido has not written Rust himself, but he praises its architectural guarantees after talking with developers building production software in it. Rust fundamentally improves upon C++ by eliminating compiler-check bypasses and cleanly solving memory management without garbage collection. While engineers building complex systems occasionally have to drop into `unsafe` code, Rust makes verification far more reliable than C++ ever could. - **Go:** Among modern systems languages, Guido considers Go uniquely approachable: “Of all the new languages, Go is probably the most Pythonic or at least the sort of the general purpose new languages.” - **Julia:** While Julia appears superficially similar to Python, syntax shifts create severe friction. Guido jokes: “when you realize oh but all the indexing is one-based and ranges are inclusive instead of exclusive you think ah nobody should ever try to code in Julia and in Python on the same day.” Julia serves its specific numerical computing niche brilliantly through aggressive compiler optimizations that Python will likely never match, but Guido doubts anyone will ever write a general-purpose production web server in Julia—joking that someone on Hacker News will probably post a counterexample within five minutes of his talk. - **TypeScript:** Turning to TypeScript, Guido acknowledges it as an outstanding language. He connects it to Python’s work over the previous six or seven years adding optional static typing (gradual typing). While Python's type-hinting initiative was not originally inspired by TypeScript—Guido was not even aware of TypeScript when Python began formulating its type system—TypeScript effectively rode the massive JavaScript wave and benefited from the language design leadership of Anders Hejlsberg.
[26:49](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1609s) Cross-Pollination Between TypeScript and Python
Guido discusses the mutual influence between Python and TypeScript, speaking warmly of his Microsoft colleague Anders Hejlsberg. Guido notes that TypeScript solved several design challenges earlier than Python, and Python’s typing Special Interest Group (typing SIG) frequently looks to TypeScript when considering extensions to Python's typing syntax and semantics. When Python developers evaluate adding a new typing feature, they often find that TypeScript was initially missing that exact capability, added it following strong developer demand, and saw great success with it.
Because JavaScript and Python share a fundamental structural simplicity, their respective type systems have much more in common with one another than Python's type system has with static, compiled languages like C++, Rust, or Java. Guido notes that the learning goes both ways: through his discussions with Anders Hejlsberg, TypeScript occasionally borrows concepts from Python, mirroring the historical ways in which JavaScript itself has adapted ideas from Python over time.
- The typing SIG regularly debates type-system extensions by reviewing TypeScript's real-world outcomes. - TypeScript and Python type systems align much more closely with each other than with C++, Rust, or Java.
[28:20](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1700s) Teaching Python First in University Curricula
Asked whether universities should teach Python before moving to lower-level languages like C++, Guido responds emphatically in favor. He points out that this shift is already a done deal across computer science education. He cites an article published in *Communications of the ACM* that surveyed top academic institutions and documented a widespread transition to Python as the standard introductory language. Even MIT, which spent decades teaching its foundational curriculum around a famous Scheme-based course, now introduces the vast majority of its students to coding via a robotics course taught in Python.
Guido delivers his view on early computer science education without hesitation:
> “There's no doubt about that that there there a few years ago there was an interesting article published in uh communications of the ACM about sort of surveys of uh major universities that had all switched to uh Python as their sort of intro to coding uh classes.”
[29:21](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1761s) The Hard Lessons of the Python 2 to Python 3 Migration
When reflecting on the transition from Python 2 to Python 3, Guido identifies the migration friction as a fundamental miscalculation stemming from Python's runaway success. The core developers assumed the transition would be straightforward because they were deeply fluent in language internals. Guido candidly admits, “In our own experience, we we thought that that transition would be relatively simple because we were all like the Einsteins of Python programming, of course, and we could translate uh code from Python 2 to Python 3 in our sleep.” They wrote code that was already clean and easy to port, mistakenly believing the entire community consisted of power users just like them who would eagerly adopt the cleaner architecture of Python 3.
```mermaid flowchart TD accTitle: Python 2 to Python 3 Transition Misalignment accDescr: Diagram illustrating the gap between core developer expectations and real-world business maintenance realities. subgraph CoreDevs["Core Developer Assumptions"] A["Core Devs: 'Python Einsteins'"] --> B["Idiomatic Python 2 code"] B --> C["Translates effortlessly to Python 3"] C --> D["Belief: Community upgrades immediately"] end
subgraph RealWorld["Enterprise Realities"] E["Domain Specialists & Non-Programmers"] --> F["Custom automation & business apps"] F --> G["Runs indefinitely without supervision like Excel"] G --> H["Breaks instantly upon Python binary upgrades"] end
D -.->|"Disconnect"| H ```
In reality, Python had quietly become essential to massive cohorts of non-traditional programmers and commercial enterprises. Businesses relied on custom applications built to solve internal needs that were handed off and left running unsupervised on servers for years—analogous to legacy Excel spreadsheets that persist across corporate reorganizations. While these applications survived company shakeups, they broke when updating the underlying Python runtime. Reflecting on this misjudgment, Guido explains that future major updates will handle compatibility completely differently:
> “So certainly if there ever is going to be a Python 4, uh well if you if you've seen my Twitter stream, if you look me up on Twitter, I pin a tweet that is like a twoline FAQ about Python 4, which is basically the transition to Python 4 will not be anything like the transition to Python 3 was because we've learned our lesson.”
[32:39](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1959s) Package Management, Dependency Hell, and Virtual Environments
Addressing modern packaging tooling such as pip 21 and its newer dependency resolver, Guido clarifies that package resolution exists outside Python the language itself. Pip is only one of several package managers, and no resolver is immune to conflict. He stresses that developers should always isolate every project using dedicated virtual environments to shield themselves from version conflicts, formerly known as "DLL hell."
However, Guido cautions that dependency hell cannot be completely eliminated, especially in fields like machine learning and data science. In those ecosystems, applications stack immense hierarchies of third-party libraries. Individual open-source communities often maintain conflicting version requirements for lower-level dependencies, making runtime errors and dependency collisions inevitable whenever an engineer attempts to import heavy stacks like pandas, PyTorch, and TensorFlow into a single project.
- Virtual environments remain the best defense against version hell. - Stacking complex ML frameworks (pandas, PyTorch, TensorFlow) frequently surfaces unresolvable transitive dependency mismatches.
[34:43](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2083s) Why Python Is Named Python: Monty Python and Pop Culture Defiance
Asked about the origin of the name "Python," Guido shares three separate influences that shaped his decision in 1989. First and foremost, he was a massive fan of *Monty Python's Flying Circus*, which he discovered when it was broadcast on Dutch television in the early 1970s; the show captivated him and helped him learn English. Because of this connection, he spent years resisting snake imagery in Python logos. When designing an icon for an early Mac OS 8 port, his limited graphic skills and a strict 16×16 pixel canvas led him to draw a Monty Python-inspired 16-ton weight instead of a reptile.
Second, the naming fit an internal tradition at CWI during the development of the Amoeba distributed operating system, where a tiny team of three or four engineers named utilities and subsystems after popular television shows. Third, Guido felt a rebellious urge against the dominant convention in computer science of naming languages after historical figures in science, mathematics, and philosophy—such as Pascal, Ada, and Eiffel:
> “And I sort of I was in a rebellious mood and I thought I don't want it to sort of be named after a Greek god or uh an important figure from the Renaissance and I didn't know those names that well either although I had learned a few of them in school and so sort of choosing references to pop culture was was my way of sort of going against that.”
[37:46](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2266s) Quantum Computing and MicroPython's Memory Constraints
When an attendee asks about the prospects of Python in quantum computing, Guido offers a skeptical, practical appraisal of hardware constraints. He jokes that even MicroPython, an ultra-compact implementation designed for microcontrollers, requires significantly more working memory than real quantum hardware currently provides. While Microsoft and other vendors distribute quantum simulation packages implemented in Python, Guido emphasizes that using Python on a classical computer to simulate quantum mechanics is not the same thing as running native Python code on quantum hardware.
[38:37](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2317s) Ending Retirement and Joining Microsoft
Guido details the events that led him out of retirement and into Microsoft’s Developer Division. After retiring from Dropbox in late 2019, his plans to spend his time traveling with his wife, cycling, and socializing with friends were abruptly derailed by the COVID-19 pandemic. Feeling trapped at home and bored, he returned to writing Python code, but quickly found himself frustrated by circular, gridlocked design debates surrounding a language enhancement he was trying to advance.
Seeking a structured outlet and a new challenge, he decided to re-enter the workforce on a part-time basis. After inquiring around the industry, he secured an interview process at Microsoft that proved surprisingly senior. Guido recalls with amusement that an administrative mix-up must have occurred, as he suddenly found himself placed into high-level interviews with corporate vice presidents—including an interview with Microsoft's Chief Technology Officer, Kevin Scott, whose executive title Guido had momentarily forgotten while they were happily chatting about technology.
[40:35](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2435s) Joining Microsoft and Seeking a Technical Focus
Guido van Rossum discusses his employment at Microsoft, expressing amusement that they decided to bring him on board given that he is an individual contributor rather than an executive or director. For the first three to four months, he spent his time simply orienting himself within the company. He took meetings with people across Microsoft who were doing interesting things with Python, ranging from machine learning to Azure Notebooks and Excel.
Despite the lack of managerial pressure telling him to start writing code, Guido realized he did not return to the workforce just to spend three days a week sitting in meetings all day long. Having been granted complete freedom regarding his focus, he set out to find a concrete project where he could get his hands dirty coding. He initially evaluated machine learning and notebooks, acknowledging the massive symbiotic success between Python and ML:
> “That field has become more successful because of Python and Python has become more popular because that field has taken off.”
However, Guido recognized that machine learning was outside his personal wheelhouse. While he knows exactly how to build web servers, web clients, database systems, or user interfaces in Python, he felt entirely out of depth when trying to write ML frameworks or simple ML applications. Despite consulting smart ML researchers across Microsoft and attempting to follow tutorials, he concluded that trying to contribute meaningfully there would be a misstep:
> “And I realized it would be a mistake to try and sort of contribute to that field because it takes like you got to spend three or four years on a PhD in the field and then maybe you can contribute something useful.”
[43:36](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2616s) The Microsoft Faster CPython Initiative and the Ecosystem
Stepping away from machine learning, Guido chose to return to his roots by building a team focused directly on speeding up Python. At the Python Language Summit, he publicly announced an initiative alongside fellow core developers Eric Snow and Mark Shannon—a longtime expert in faster Python virtual machines. Employed as Microsoft staff and contractors, the team is working directly on CPython performance. While they landed a few minor contributions into Python 3.10 right before its beta release, the team now views the coming year as their runway to meaningfully move the needle on performance for Python 3.11.
Guido notes that this performance push aligns with renewed interest across the tech industry: - **Facebook / Meta:** An internal team recently open-sourced their performance work focused primarily on Python 3.8. - **Piston:** Built by former Dropbox engineers, Piston v1 originated as an open-source Dropbox project, while Piston v2 was recently open-sourced, targeting Python 3.8. - **Pyjion:** Maintained by Microsoft Developer Advocate Anthony Shaw after publishing his book on CPython internals, Pyjion implements a JIT compiler for Python based on the.NET framework.
```mermaid flowchart TD accTitle: Python Performance Initiatives Overview accDescr: Diagram showing Microsoft's CPython team and other notable industry projects aimed at speeding up Python.
subgraph MSFT["Microsoft CPython Team"] GVR["Guido van Rossum"] MS["Mark Shannon"] ES["Eric Snow"] Target["Target: Python 3.11"] GVR --- MS --- ES --> Target end
subgraph Industry["Industry Projects"] FB["Facebook Team (Python 3.8)"] Piston["Piston v2 (ex-Dropbox, Python 3.8)"] Pyjion["Pyjion (Anthony Shaw /.NET JIT)"] end ```
[47:03](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2823s) Why Python 4 Is Treated as an In-House Joke
When asked whether the community should expect a "Python 4," Guido explains that the core development team treats the phrase as an internal joke born out of the painful migration from Python 2 to Python 3:
> “And so it's it's almost taboo to talk about a Python 4 in a serious sense. And most of the time, uh, when people say, 'Oh, we'll do that in Python 4,' everyone is in on the joke. And, uh, it's just a funny way of saying that will never happen.”
Python has shifted to a strict annual release cadence. Following Python 3.9, version 3.10 entered beta with a scheduled final release for October. Releases will proceed predictably with 3.11, 3.12, and onward. Guido quips that they can easily keep incrementing up to 3.99 before having to add another digit, noting that moving from one digit to two (3.9 to 3.10) was far less traumatic than the jump between 2 and 3. Speed improvements will roll out incrementally across these releases rather than through a single disruptive milestone.
[49:37](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=2977s) Potential Breaking Changes: C APIs, Reference Counting, and the GIL
Guido reflects on what severe technical requirements could theoretically force the core team to increment the major version to 4.0. The primary trigger would not be surface language syntax, but breaking backwards compatibility for C extensions:
- **Memory Management & Garbage Collection:** Python currently relies on reference counting, and the internal machinery is directly exposed to third-party C extensions. This tight coupling makes it exceptionally difficult to refactor interpreter memory management. - **The Global Interpreter Lock (GIL):** Larry Hastings' prior "Gilectomy" project attempted to excise the lock entirely, though Hastings appears to have moved on to other hobbies after encountering steep headwinds. - **Sub-Interpreters as an Alternative:** Guido and Eric Snow favor a different architectural path: per-interpreter GILs via multiple sub-interpreters sharing a single operating system process without shared mutable state. Guido notes this concurrency model is cleaner and more effective for multi-core scaling than the shared-everything threading typical of Java or C++.
```mermaid flowchart LR accTitle: Sub-interpreter Concurrency Model accDescr: Diagram contrasting shared-everything threading with isolated sub-interpreters inside a single process.
subgraph Process["Single OS Process"] subgraph Sub1["Sub-Interpreter 1"] GIL1["Own GIL"] State1["Isolated Memory"] end subgraph Sub2["Sub-Interpreter 2"] GIL2["Own GIL"] State2["Isolated Memory"] end Switch["Fast Context Switching / Message Passing"] Sub1 <--> Switch <--> Sub2 end ```
Because sub-interpreters can avoid broad breakage, Guido believes major C API overhauls can be carried out gradually with deprecation cycles to protect critical third-party libraries such as NumPy, PyTorch, TensorFlow, and pandas. As a result, a 4.0 release remains undesirable:
> “I'm I'm not thrilled about the idea of of Python 4 and nobody in the core dev team really is. So probably there never will be a 4.0 and will just keep numbering uh until 3.33 at least.”
[53:51](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=3231s) Transition to Personal Interests
As the session nears its end, the host pivots from technical and organizational roadmaps to human-interest questions, asking Guido about what hobbies he pursues outside the Python programming ecosystem. Guido begins answering by noting that he enjoys reading.
[54:24](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=3264s) Personal Life, Family, and Outdoor Hobbies
Reflecting on his personal life away from programming, Guido van Rossum describes himself with characteristic modesty, declaring: “I'm a very boring person.” He shares that he prioritizes his family, though his approach to privacy has changed significantly over time. When his son was born nineteen years earlier, he casually sent out a birth announcement to the entire Python mailing list. Looking back, he notes that he would never do that today, as his family prefers to keep their lives much more private. He enjoys reading science fiction and fantasy, as well as watching shows in those genres, often spending time watching them with his nineteen-year-old son, Orla. Guido admits with a laugh that Orla aspires to be a bass player in a metal band, observing that it is about as far removed from his parents' tech-oriented careers as possible—a classic adolescent path that Guido fully embraces and supports.
Beyond his indoor interests, Guido enjoys spending time outdoors hiking and biking, emphasizing that he keeps his physical activities relaxed rather than extreme. Contrasting himself with a friend who occasionally bicycles all the way across the United States, Guido insists that kind of feat is entirely beyond him. Instead, his ideal outing involves taking a casual two-hour ride to refresh himself mentally before loading his bicycle onto the back of the car and heading home. The host remarks on how pleasant that lifestyle sounds in California's sunny climate, prompting Guido to agree wholeheartedly that he and his family love living there and are very happy.
- When his son was born 19 years ago, Guido shared the news directly via the Python mailing list, a public move he would not repeat now. - Guido's son, Orla, wants to pursue a career as a bass player in a metal band, representing a sharp contrast to his parents' professional backgrounds. - Unlike friends who participate in extreme cross-country endurance cycling, Guido prefers low-intensity two-hour bike rides that boost his mood.
[56:10](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=3370s) Session Conclusion and Final Farewells
As the live session hits its scheduled time limit, the host draws the interview to a close, expressing personal gratitude for the opportunity to speak with Guido and learn more about both the history of Python and his personal background. Guido responds warmly, offering praise to the host: “You've been a very good interviewer.” The host extends thanks to the audience watching the stream, expressing excitement to stay in touch and track Guido's ongoing Python-related engineering initiatives at Microsoft. After brief closing remarks and mutual expressions of appreciation, Guido and the host say their goodbyes to the viewers, bringing the broadcast to an end.
## Notable quotes > [22:29](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1349s) Of all the new languages, Go is probably the most Pythonic — Guido van Rossum
> [09:26](https://www.youtube.com/watch?v=aYbNh3NS7jA&t=566s) it's my language, not theirs; you can design your own language. — Guido van Rossum
## Mentioned Guido van Rossum, Francesca, Dion, Tim Peters, Barry Warsaw, Anders Hejlsberg, Kevin Scott, Eric Snow, Mark Shannon, Anthony Shaw, Larry Hastings, Orla van Rossum, Python, ABC, Amoeba, C, C++, JavaScript, WebAssembly, Brython, Rust, Go, Julia, TypeScript, Scheme, Pascal, Ada, Eiffel, MicroPython, pip, pandas, PyTorch, TensorFlow, NumPy, SciPy, Piston, Pyjion, Centrum Wiskunde & Informatica (CWI), University of Amsterdam, Google, Dropbox, Microsoft, Microsoft Reactor, Meta, Facebook, MIT, Monty Python's Flying Circus, Communications of the ACM, Usenet, Hacker News
## Video description Guido van Rossum is a Dutch programmer best known as the creator of the Python programming language, for which he was the "Benevolent dictator for life" (BDFL) . Come join us for an open Q/A "Ask me Anything" to get to know how PyCon was born and Guido's amazing journey
For more on Python, click here: https://developer.microsoft.com/reactor/topic/2/?wt.mc_id=youtube_0_video_reactor
For more community and learning events from Microsoft Reactor, click here: https://developer.microsoft.com/reactor//?wt.mc_id=youtube_0_video_reactor
[eventID:13426]
[Source](https://www.youtube.com/watch?v=aYbNh3NS7jA)