|
|
Subscribe / Log in / New account

On becoming a Python contributor

By Jake Edge
July 30, 2025

EuroPython

In the first keynote at EuroPython 2025 in Prague, Savannah Bailey described her path to becoming a CPython core developer in November 2024. She started down that path a few years earlier and her talk was meant to inspire others—not to slavishly follow hers, but to create their own. In the talk, entitled "You don't have to be a compiler engineer to work on Python", she had lots of ideas for those who might be thinking about contributing and are wondering how to do so.

[Savannah Bailey]

She noted that she had recently gotten married and changed her last name from "Ostrowski"; she is "a bit in-between last names right now", she said with a chuckle. Most recently, she has been contributing to the new just-in-time (JIT) compiler for CPython, including as a co-author of PEP 744 ("JIT Compilation"). She is also the maintainer of the argparse module in the standard library, which attendees may "know, use, love, [or] hate".

She is the treasurer for the governing board of the Jupyter Foundation and her day job is to work on Python developer experience at Snowflake. As a mostly self-taught developer, she does not have a computer-science degree, which is something that she "used to be very self-conscious about" but now sees as a strength.

Most importantly, "I am a cat mom of three", complete with a photo of said cats and predictable reactions from the audience. "What's a keynote without a cat picture?" That question started something of a competition throughout EuroPython, featuring more cats, naturally, but also dogs, ferrets, and other pets.

Back to 2020

Bailey said that she wanted to take the audience back to 2020; "no, not that part of 2020, not the sourdough starters and the existential dread". 2020 is when she got her first job working on Python developer tools and her first time working as a product manager; prior to that, she had developed in Python for five years or so. She had "fallen into software" after studying at an engineering school in Canada; she taught herself to program because of the "amazing internships" that were available to programmers.

She started working on an unnamed project in 2020, which became the Pylance language server; it "provides the UX [user experience] bells and whistles and a great editing experience" by adding syntax highlighting, auto-completion, auto-imports, and so on for Python in Visual Studio Code. That exposed her to lots of new things, including "the guts of Python". Pylance is built on top of a static type checker called Pyright, so she learned about type annotations, which she had never used when developing in Python. She and her team were also contributing to open-source projects like typeshed for Python type annotations and referencing PEPs as part of their work. "I was learning bits and pieces about how Python worked under the hood and the open-source ecosystem around it."

After a few months of the "most fun I've ever had in my career", she thought that "it would be so cool to contribute to Python someday". But then came a followup thought: "Let's be real, that's probably never going to happen". She did not know C well—"there's that big C in front of CPython"—and was not working as an engineer anymore at that point. So she did what seemed to be the rational thing and shelved the idea. She thinks that a lot of people have a similar experience where that voice in their head causes them to set aside various goals and dreams because they are "never" going to happen.

Good news

But the good news is that it turns out that she was wrong; "that line of thinking is just 100% wrong", so wrong, in fact, that she wanted to spend a 45-minute keynote slot describing just how wrong she was, she said with a laugh. But, she acknowledged that those feelings of inadequacy are real and did not want to downplay them; "I had those doubts, I still sometimes have those doubts."

Like many others, she originally thought that contributing to Python "always means that you are knee-deep in interpreter internals", which is intimidating for those without the requisite background. The belief is that a Python contributor is "some kind of 10x programming wizard that dreams in bytecode" and spends all of their available time improving Python. There are some contributors and core developers who are like that, perhaps, but the idea that all contributors know "a bunch of stuff that you don't know, and you could never learn, could really not be further from the truth". Python contributors are just people, with different backgrounds, working on various parts of Python at different rates; they have families, hobbies, and other passions beyond just Python.

She thinks that many people already have useful skills for contributing to Python. Those who have written, tested, and debugged Python code, or who like to write documentation, can apply those skills to contributions. Work from other areas of computing likely qualify as well. "Or, maybe, if you just like being thrown into the deep end with a tricky problem, then I bet you already have skills that are relevant to support contributing".

The main barriers to starting to contribute are threefold. A lack of understanding about the different kinds of contributions is one. Another is figuring out how to apply existing skills to Python contributions. The third is to address the impostor syndrome "that gets in the way".

She wanted to dispel the notion that a contribution is always a commit that gets added to a repository somewhere. Asking questions that surface a bug, filing a bug or issue that saves time for others, improving documentation to help people avoid an edge case, or reviewing a pull request and asking for clarification, all help move the project forward, Bailey said.

She started contributing by doing bug triage, which is the process of "combing through open issues and helping to figure out if something is actually a bug", which Python versions it affects, how it can be reproduced, and so on. "For maintainers, triage work is gold." If there is a bug, fixing it is, of course, also welcome, but the triage itself saves lots of time for maintainers.

Triage also provides a nice on-ramp for contributors. She learned a lot about how to build CPython, run its tests, and about the workflows that are used in the project. But, most importantly, she got to know the people involved in the project, she said. "It gave me a sense of how the team communicates and makes decisions."

Over time, she started noticing patterns in the bugs and in parts of CPython that had lots of issues that were unaddressed for a long time. One of those areas was the argparse module; without doing triage, she would not have even known that the module needed help.

Documentation is another good way to learn about CPython. It is incredibly valuable to users, both old and new, but is difficult to write—often harder than the code itself. Writing off documentation as "not real work" is common, "but honestly I think that's total garbage".

No internals needed

Something that is either not well-known or has been forgotten is that much of the standard library is written in pure Python; "it's not C, it's not deep internals, it's just Python". So most Python programmers already have the skills needed to contribute there. She suggested starting as you would with a new job: pick something small, keep learning more about the code base, and build up from there.

So far, she had shown that potential contributors do not need to understand the internals of CPython in order to do fruitful work for the project—triage, documentation, pure-Python standard-library code—but she also wanted to point out that those who want to learn about the interpreter can definitely do so. "You can learn if you're interested, it is totally in the realm of possible." She started only knowing about the interpreter at a high level, got interested in the JIT compiler, started asking lots of questions, poking around in the code, reading and re-reading PEPs, and so on. Eventually she started contributing to the JIT.

She started her learning "in a way that felt really natural to me, by applying my background in DevOps and infrastructure to solve some pretty real problems for CPython's JIT compiler". She really loves working on DevOps tasks, such as build tools and continuous integration, which are "unglamorous and hopefully invisible parts of the code base". Doing those jobs right makes "people happier and more productive, even if they never really know why".

When people think of the JIT compiler, they often think things like "PhD-level expertise required", and the topic does seem kind of academic to her at times. But whenever she traces through the interpreter code or reads a pull request for the JIT compiler, she learns lots of new things; sometimes she feels over her head, "but, honestly, I love that feeling". Earlier when she was over her head, it made her feel like she did not belong; it amplified her self-doubt. She has learned "how to get comfortable with being a bit uncomfortable" and she was able to contribute while still learning by applying skills that she already had.

Her DevOps experience was what the JIT project needed at the time she started contributing because it is important to ensure that CPython can reliably be built for and run on various platforms. So, she helped on upgrading the LLVM version used to build CPython from 16 to 18 and then to version 19. She also worked on ensuring that the JIT builds correctly for both Intel and Apple-silicon Macs. Making the continuous-integration pipeline "faster, more reliable, and less painful for contributors and other core developers" is another area she worked on; for example, she added new continuous-integration jobs for building the JIT into the free-threaded version of CPython.

She also authored PEP 774 ("Removing the LLVM requirement for JIT builds"), which has been deferred for now; "that's not the point, it may never be accepted, but I would still be proud that I wrote it" because writing a PEP seemed completely out of reach to her when she started out. Writing it did not require a special degree or compiler knowledge; it required DevOps, Python, documentation, and research, which are skills and knowledge that she has. To contribute, "you just need to have something to offer and the courage to start showing up".

Community

The Python community is perhaps the biggest thing that helped her over the hurdle of contributing. Before her first commit she had people cheering her on and it has been the community that has kept her coming back. She noted that the famous quote from Brett Cannon ("I came for the language but I stayed for the community") is "100% true" for her as well.

At PyCon US 2023, scientific Python contributor and former steering council member Carol Willing approached Bailey and asked if she had ever thought about becoming a core developer. She responded by laughing, and then crying, "which was kind of awkward because there were a lot of people around". She said that she was interested, but had no idea where to start, which she thinks is a common feeling. That question really changed things for her, "because it took something that I had only dreamed about and made it feel tangible".

A few months went by without any real progress toward contributing when she got together with Willing when she was in Seattle, near where Bailey lives. At the dinner, Willing gave her a bit of a pep talk after finding that Bailey was still interested but was "still figuring out if I can even be useful here". Willing suggested contacting other core developers to get their perspectives on contributing.

The next day, she reached out to her Microsoft colleague Brandt Bucher, who started the CPython JIT project, to ask him if they could chat. That led to several months of nearly weekly meetings for him to answer questions and for them to talk about CPython internals; he also supported her first contributions to CPython along the way. The technical help was useful, of course, but it was the conversations and the relationships with Bucher, Willing, and others "that made me feel like I belonged".

She was sharing all of this, "not because I think it is extraordinary", because that is not what she thinks: "I think it's a story about community". It is about people taking time to share what they know and to make others feel welcome. Not everyone has those connections—she did not when she started working on Python development tools—but they can be built over time. "You can reach out, you can ask questions, you can take those first steps yourself."

Her ask for attendees was to "find your community"; maybe that's on the Python discussion forum, at EuroPython, in the CPython issue tracker, in the documentation or translation communities, or elsewhere. "You should introduce yourself, you should ask questions, you should offer to help, because that's actually how it all starts."

She showed pictures of attendees at the Python Language Summit and core developer sprint, noting that no two people in those pictures took the same path to contributing. She had presented her path in the talk, "your path might look totally different and that's not just okay, it's actually really really important". There is no need for 100 of her working on CPython; it is the diversity of skills and perspectives that is needed. "That's actually how Python grows, how open source stays open, not just to code but also to people."

Getting started contributing does not mean you need to know everything first; "wherever you start, you should just start". She did note that doing so can be scary at first, "but you should just do it scared". Worrying about asking naive questions or being wrong is natural, but can be overcome; beyond that, the naive question is probably one that others have but are too scared to ask. The smartest people she knows "are wrong literally all the time, and they ask a lot of questions and admit when they don't know the answer". Maybe, once you get started contributing, "you'll realize that it's not really that scary after all".

Toolkit

With luck, she had inspired some curiosity about contributing and given attendees the sense that it is possible for them to contribute; but where should people go for more information? Her "contribution toolkit" had four sites that she suggested people explore, starting with the CPython GitHub repository. It has issues and pull requests for the whole project, including the interpreter, standard library, and documentation; "it all happens here". Watching the activity in the repository is a good way to get started by seeing what changes are being proposed, how decisions are being made, and places where some help is needed.

The PEP index is another site to explore; PEPs document major changes to the language, so they provide some historical context for decisions made by the project. "If you've ever wondered why something works the way it does in Python, there's probably a PEP for it."

For questions about PEPs or anything else Python-related, the Python discussion forum is the right place to go. That is "where a lot of bigger picture conversations happen, around features, governance, packaging, docs, typing"; it is a good place to post ideas. She recommended reading the forum for a while before posting, as there is a lot that can be learned that way; when posting, please "be nice and kind", she asked, so that the forum can "continue to be a really good experience for everyone".

Lastly, she said that the Python Developer's Guide is "really your roadmap to contributing". It covers things like setting up a development environment, building CPython, running tests, submitting pull requests, and so on. There is also information about the criteria for joining the triage team and for becoming a core developer. The experts index in the guide is useful to figure out which core developers are active in any given part of the project. "These are some great places to start: pick a link, open the tab, start poking around."

She closed by showing her response to the vote to promote her to the core-developer team, noting that "it captures what this talk has really been about": the people that make Python possible. Her slides are available in her GitHub repository and a video of the talk should appear before long in the EuroPython YouTube channel.

[I would like to thank the Linux Foundation, LWN's travel sponsor, for travel assistance to Prague for EuroPython.]


Index entries for this article
ConferenceEuroPython/2025
PythonCommunity


to post comments

Plot twist!

Posted Jul 30, 2025 15:36 UTC (Wed) by hynek (subscriber, #55397) [Link]

Shortly after, Savannah was announced as the next release manager for Python 3.16 and 3.17: https://discuss.python.org/t/welcome-the-3-16-and-3-17-re... 🎉

My advice

Posted Jul 31, 2025 9:12 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

I encourage everyone who wants to start on this path to hang out a bit on the python discuss.

Getting a simple PR accepted to simply add a new setsockopt flag is a gargantuan effort.

The moderators are quite happy to mute you if you dare to reply to people flaming you, who of course won't get muted.


Copyright © 2025, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds