Making Python Faster with Guido and Mark
This episode is the first of several that dive into some of the active efforts to increase the speed of Python while maintaining compatibility with existing code and packages.
Who better to help kick this off than Guido van Rossum and Mark Shannon? They both join us to share their project to make Python faster. I'm sure you'll love hearing what they are up to.
Episode Deep Dive
Guests Introduction and Background
Guido van Rossum is the creator of Python, often referred to as Python’s “benevolent dictator for life” (BDFL) until 2018. After retiring from Dropbox and stepping away from some leadership roles, he joined Microsoft to form a small team dedicated to optimizing CPython’s performance.
Mark Shannon is a Python core developer who has worked extensively on performance, compiler internals, and just-in-time (JIT) approaches for speeding up Python. His proposal, nicknamed the “Shannon Plan,” is guiding much of the current CPython optimization efforts.
What to Know If You're New to Python
If you're new to Python and want to fully appreciate the details in this episode, here are a few key points:
- CPython vs. Other Runtimes: CPython is the “default” implementation of Python—the one you get when you download Python from python.org. This episode centers on making that version faster.
- The GIL (Global Interpreter Lock): CPython uses a lock to ensure only one thread runs Python code at a time, which can limit CPU parallelism. You’ll hear discussions around attempts to remove or work around it.
- Reference Counting and Memory: Python primarily uses reference counting to manage memory. This is integral to how and when objects are cleaned up—important for performance.
- Performance vs. Flexibility: Python’s dynamic nature makes it incredibly flexible. However, that same flexibility introduces performance challenges that many contributors (including Guido and Mark) are now tackling head-on.
Key Points and Takeaways
- Speeding Up CPython as a Primary Goal
Python’s huge user base relies on the CPython implementation, so any speed improvement here helps nearly everyone. Rather than creating a specialized fork or a separate engine like PyPy, this approach keeps total compatibility with existing code and extension modules.
- Links and Tools:
- Microsoft’s Dedicated Python Performance Team
Guido formed a small, focused team at Microsoft—initially him, Mark Shannon, and Eric Snow, with a later addition of Brett Booker—to work on CPython performance full-time. Their efforts are entirely open-source, merging changes into mainline Python rather than maintaining a private fork.
- Links and Tools:
- The Shannon Plan
Mark Shannon proposed a four-stage roadmap aiming to achieve roughly a 5x speed boost over several Python releases. While the stages have somewhat merged in practice, they include specialized “hot paths,” better memory layout, some level of inline or tiered JIT, and continuing refinements.
- Links and Tools:
- Discussion on Python-Dev mailing list (search for “Shannon Plan”)
- Links and Tools:
- Keeping Python’s Codebase Maintainable One critical constraint is that any speedup must not make CPython’s C codebase so complex or specialized that few can contribute. Writing raw assembly or removing the GIL outright in a naïve way could hurt long-term sustainability. This maintainability ethic also ensures minimal disruption for the broader ecosystem.
- Stable ABI and Extension Module Compatibility
CPython has a stable ABI (Application Binary Interface) that lets extension modules continue working without recompilation across minor versions, provided they use a “limited API.” The team does not want to break this or impose major rewrites on maintainers, preserving Python’s strong community library support.
- Links and Tools:
- Comparisons with Other Approaches Projects like PyPy offer speed benefits but have partial support for certain C extensions, which is a deal-breaker for many. Meanwhile, Sam Gross’s no-GIL fork shows promise for multi-core parallelism but still remains separate from mainline CPython. Guido and Mark’s path is incremental, focusing on broad compatibility.
- Zero-Overhead Exception Handling
Python 3.11 introduced a more efficient exception handling mechanism that skips certain extra instructions if no exception is thrown. This can lead to noticeable performance boosts in real-world code with many
try
blocks orwith
statements. - JIT Compilation Plans Later phases of the Shannon Plan mention a modest or miniature JIT. The idea is to compile small “hot” segments of code as they run, with quick fallbacks to the interpreter. This incremental approach is less risky than a full method-at-a-time JIT that might degrade performance unpredictably.
- The Role of the Developer in Residence
Although not directly about performance, the Python Software Foundation (PSF) now funds a developer in residence (Łukasz Langa) to help triage issues, review PRs, and keep contributions flowing smoothly. This organizational support complements the Microsoft effort and ensures the language stays healthy overall.
- Links and Tools:
- [PSF Developer in Residence announcement](https://pyfound.blogspot.com/search/label/Developer in Residence)
- Links and Tools:
- Impact on the Community and Ecosystem Beyond speed, these changes save energy, reduce hardware budgets for large deployments (like Dropbox), and help Python remain competitive for both large-scale services and iterative data science workflows. The team encourages testing alpha builds and sharing real-world benchmarks.
Interesting Quotes and Stories
- Guido on “Retiring”: “I just like the idea of retiring. So I try to see how many times in a lifetime I can retire… but then the pandemic hit, and I found myself wanting to code in a team again.”
- Mark Shannon on Python as a Challenge: Referencing Armin Rigo, “Python is such a great language to use and such a challenge to optimize,” underlining how dynamic features make for unique performance hurdles.
- Guido on Team Culture: “We don’t have a private fork. We work fully in the open, merging changes in as soon as we can so everyone benefits.”
Key Definitions and Terms
- CPython: The default and most widely used implementation of the Python language, written in C.
- GIL (Global Interpreter Lock): A mechanism in CPython that allows only one thread to execute Python bytecode at a time.
- JIT (Just-in-Time Compilation): A technique where code is compiled on the fly at runtime for performance.
- Stable ABI: A set of C-level interfaces in Python guaranteed not to break across certain versions, allowing compiled extension modules to keep working without recompilation.
Learning Resources
Here are a few curated courses from Talk Python Training to help you go deeper into Python, its performance, and internals:
- Python for Absolute Beginners: If you’re new to Python, this course gives you a thorough foundation in the language.
- Python Memory Management and Tips: Learn about reference counting, garbage collection, and performance considerations in Python’s memory model.
- Python 3.11: A Guided Tour Through Code: Dive into Python 3.11’s new features, including its performance improvements and refined exception handling.
Overall Takeaway
Python is evolving to meet the rising demands of performance-critical applications. Thanks to the work of Guido, Mark, and other core developers, CPython is seeing meaningful speedups without sacrificing the language’s hallmark compatibility and simplicity. This renewed emphasis on performance—combined with the community’s commitment to maintainability—ensures that Python will remain not just easy to learn, but also fast enough to keep up with cutting-edge needs.
Links from the show
Mark Shannon: linkedin.com
Faster Python Plan: github.com/faster-cpython
The “Shannon Plan”: github.com/markshannon
Sam Gross's nogil work: docs.google.com
Watch this episode on YouTube: youtube.com
Episode transcripts: talkpython.fm
--- Stay in touch with us ---
Subscribe to Talk Python on YouTube: youtube.com
Talk Python on Bluesky: @talkpython.fm at bsky.app
Talk Python on Mastodon: talkpython
Michael on Bluesky: @mkennedy.codes at bsky.app
Michael on Mastodon: mkennedy