Become a Python Core Developer in 3 Easy Steps - Tomas Roun

[applause] All right. Thanks a lot, Ned, uh, for the introduction. So, hi everyone. Uh, it's real honor and pleasure, uh, to be here today. And I must confess, I've never presented in a room as big as this one. So, it's a new experience for me. Uh, but I have a talk for you today. Become a CPython core developer in three easy steps. So what's the motivation for this talk? Well, one to get more of you interested in contributing to CPython and eventually becoming core developers as well because you can never have too many core developers, right? And another reason is um I've been contributing to CPython for a few years now and oftent times when I speak about it with other people uh even my friends and colleagues a lot of them are interested in getting involved with the project. Uh but a lot of them get stuck right at the beginning because they don't know how or where to get started. uh because CPython is a very large project and it can be very overwhelming especially for newcomers uh who don't know uh where their help might be needed or they don't know how to find uh let's say the lowhanging fruit that kind of gets them hooked into the project. So uh I want to spend the time here to kind of give you some uh concrete ideas of what you can actually do and how you can meaningfully contribute to the project. And I want to also demystify a bit the process of actually becoming a core developer because as it turns out it's actually uh easier than it seems. First just a bit about me. So uh my name is Thomas. I've been contributing to CPython for a few years now and since last year I am also a core developer. Now maintaining open open source typically doesn't pay the bills. So I also have a day job working at CERN where funnily enough I actually do get paid to work on open source which is pretty cool. Uh now CERN if you haven't heard of it CERN is the largest physics lab in the world situated uh close to Geneva Switzerland. Uh we operate the LHC the large hedron collider which among other things found the Higs Bzon uh back in 2012. I am also into mechanical keyboards. So, if this is something you're also into, come talk to me about it. I'd love to chat. And these are just some of the keyboards I built and uh designed. Uh just a word of advice, it's a very expensive hobby, so uh prepare your wallet before you get into it. All right, so first things first, what is a Python or CPython core developer anyway? So, you can think of core developers as basically Python maintainers. So we have commit access to the CPython repository and as a result we also see the green merge button on GitHub as well. Uh in more abstract terms uh core developers are people trusted by the community to help maintain and improve Python in any shape, way or form. Things like fixing bugs, uh implementing new features, mentoring new people or speaking about CPython at conferences like your Python. Now you might be wondering how many core developers are there actually. So all in all there are about 209 exactly 209 core developers. Uh but this is really counting from the beginning of Python. If you only look at how many active core developers there are these days it's about 50 depending on how you define what active means. Uh but as you can see uh we keep adding more core developers all the time. So for example back in 2024 there were nine people uh that joined the team and this year already you can see we had five people becoming core developers as well and it's just the middle of the year so we might have a couple more uh uh joining again later. Now you might be wondering why would I want to become a core developer? What's in it for me? There are things like prestige recognition. it might be a bit easier to find a job uh which could be useful especially in this economy right um but there are other things uh personally for me Python is just my favorite programming language and it's my way to give back to the community and also as a core developer you get a custom python.org email address so I have thomaspython.org perk, which I don't really use it for anything. I just think it's really cool. So, that's one thing you get. Uh, yeah, if you're curious, there are actually a lot more substantial perks you get as a core developer. So, uh, Mariata, who is a longtime core developer, has a really nice blog post about it where she lists all the things uh, you get access to as a core developer. So, if you're interested, definitely check it out. Now, how does one actually become a core developer? So there is no one-sizefits-all, but what typically happens is something like this. So you start as a Python user. So somebody who uses Python who hopefully and presumably also likes Python, which I guess is most of us in the room. And then you make a contribution to Python. And in the second half of the talk, I'm going to focus really on that. How you can go from being a user to being a contributor. But for now, let's just assume maybe you fix a bug, you fix a typo in your documentation or anything, you become a Python contributor. Now, if you do this for a while, you become more consistent, you have some high quality contributions, a core developer is going to notice you and he or she is going to ask you uh if you want to become a triager. Now, what's a triager? So triagger is kind of the first official role uh you have in the project. Um you become a member of the Python organization on GitHub and you get some privileges on the issue tracker things like you can close issues, you can assign labels, you can assign people to issues, stuff like that. Uh but more than that uh triager is sort of a recognition for the work that you have done and also a recognition for your potential to eventually become a core developer. So triagger is kind of like a cord of light uh if you want to think about it like that. [snorts] And in fact typically typically the person that asks you to become a triager also becomes your mentor uh on your way to becoming a core developer as well. Now as a triager again if you stay consistent uh with the project for a while and you make again some high quality contributions and it's clear that you can work independently responsibly and you get along well with other people then you might get nominated to become a core developer. Then all the other cores take a vote and if the vote is successful you actually become a core. So this is pretty much how it works for most people. So you start as a user, you make some contributions, you get interested in the project, you keep doing it for a while, you become a triager, you keep doing that for a while, and then you become a core developer. Now you might be asking, so how long does this actually take? You know, how much effort, how much time should I expect to, you know, uh, dedicate to this? So I have some statistics about that and I hope that the graphs are going to be legible, but if not, I'm just I'm going to read what's on them. So don't worry. Uh so I looked at two things. I look at one, how long does it take to go from your first contribution to becoming a triager and this takes about 10 months and then how long does it take from being a triager to go to a core dev and this is about nine more months. So all in all if you squint a little bit it takes about one and a half years to go from your first contribution to becoming a core developer. Now I think this is a very actually very fast uh the first time I saw it I wasn't expecting it to be uh so little in quotes uh because there's a lot of things you have to learn uh about the project about the codebase about the dos and don'ts about why we do things a certain way so one and a half years is a very I think a very optimistic number for people who are interested in getting involved with the project. Now another thing I looked at is um kind of to try to measure a bit the effort required let's say uh to become a core developer. So I looked at two things again. How many issues people are involved in by the time they become a core developer and also how many PRs they author by the time they become a core developer. And for PR specifically it's about 70. So again if you assume one and a half years to become a core it's about one PR per week which again is not a huge amount of effort if you think about it. It really means that you don't have to make uh contributing to CPython a full-time job to meaningfully contribute to the project which I think is really cool. You can just spend a few hours per week on it and you know you kind of progress uh and you know do something meaningful which is really cool right because a lot of us have full-time jobs so we don't have time you know to spend 40 hours on this. Now um so that was a bit about how you can become a core developer. Now in the second half of the talk I want to give you some concrete things some concrete ideas of what you can do. But first I just wanted to give a quick shout out to Savannah which I guess I don't need to introduce because she had a talk here 1 hour ago. Uh but uh the talk I want to reference is from last year and I want to echo her message which is you don't have to be an expert. You don't have to be a compiler engineer uh to work on Python. I don't consider myself to be an expert in any of the things that I worked on. I worked on the JIT. I worked on CPython internals. I worked on parts of the standard library. Lots of other cool things. Uh again, I don't see myself as an expert, but I still got to work on some really cool stuff. So, this is just to remind you that, you know, don't be intimidated. You don't have to be like a super genius to work on Python. There are so many things that anybody can do. You just need to know Python a little bit. That's all. So now uh for the things that you can actually do today to help out with CPython. So one idea uh that you can do is to help us increase test coverage. So CPython has thousands and thousands of tests. But like any other project that changes over time, the test coverage goes up and it also goes down. So there are lots of parts of the codebase which are not covered by any tests at all which is not great. So what you can do just compile CPython locally run the test suite with coverage enabled find the line which is not covered by any tests and write a test for it. It's a very easy thing to do and it also teaches you a lot about the module that you are writing uh the test for. Now another idea uh another thing that you can also do is to help out with type shed. So in case you don't know uh the CPython standard library uh basically doesn't have any type annotations in the source code. The type annotations are kept separate in this project called typed and typed is actually what a lot of idees and language servers use as the source of truth uh to tell you let's say the return types and the argument types of a lot of the standard library functions. So now because CPython and Typeshhat are two separate projects, they get out of sync. Uh for example, you can imagine you add a function uh to CPython, but then you don't add the type annotation to type and now it's out of sync. So there's a lot of lowhanging fruit in the project that you can work on if you are at all interested in typing. Again, you don't have to be a typing expert. Uh you just need to be interested. So this is another idea uh another thing that you can help us out with as well. Now I've talked a lot about contributing and making contributions but I just want to make it clear that um contributions are not just writing code and there are lots of other ways uh you can contribute uh that don't involve writing any code at all uh which are arguably even more important. So for example issue triage. So, if you go to the CPY issue tracker, you'll see that we have, I believe, over 7,000 open issues uh today, and the number is not going down anytime soon. And on top of that, we get like 10 uh new issues every single day, even you know, on holidays. So, somebody has to go through these issues and, you know, figure out what they are and what to do with them. things like is it a bug report, is it a feature request, is it some kind of security issues that we need to fix right away, right? So there are a lot of questions that need to be answered specifically for bugs, things like is it actually a bug or is it a documented behavior or can it be reproduced or is some kind of you know race condition something Heisenbug you know whatever that is hard to reproduce. Is it platform specific? So you know does it only happen on Windows which you know happens sometimes and other things like can you bisect it to a specific commit because that helps us figure out how to actually fix it. So issue triage is another thing you can help us out with you can just you know show up uh read the issues figure out if there's something you can see that you can help with you can just go and do it. Uh, another thing that you can help out with is the documentation. So, documentation doesn't write itself. Uh, there's always more stuff that can be documented, more examples to be added, uh, grammar to be fixed and improved. There are also community translations um, for translating the documentation into other languages as well that you can help out with. And if you don't necessar ne necessarily like writing documentation, you can also help us maintain the sphinx theme for the documentation and even the official python.org website. The source for that is also on GitHub. So you can also go there. There are also a bunch of bugs that need to be fixed. So you can also check that out. Now last but not least, uh code reviews. So again, if you check out the CPython repository, you'll see I think there are currently over 2,000 open PRs. And uh again so the issue is not really not having enough code contributions from people. The issue is really uh not having the manpower to review them all. So if you are the kind of person that likes doing reviews and I know some of them exist, right? Probably not many, but if you like doing that sort of thing, we would absolutely love to have you because this is really the number one bottleneck I would say when it comes to getting new changes into Python is just the lack of reviewers that want to review stuff. And code is not the only thing that needs to get reviews, right? Peps, Python enhancement proposals also need to get reviews, right? Obviously, you have to look at a technical content, but there are other things that you can help with. Things like the grammar, style, consistency, clarity, other things that anybody can help out with as well. If it's a feature P, it might also come with a reference implementation that also needs to be tested to figure out, for example, uh if there are any edge cases that were not covered in the PEP uh and uh things like that. It's also a great way to stay up to date with really the the most bleeding edge stuff that is going on in Python. So, you know, if you don't want to even if you don't want to review anything, you can just keep an eye on the Peps repository. And so these were some um ideas uh for what you can do. It's definitely not an exhaustive list. There are many many other things you can help out with. But I just want to give you a word of caution before you just jump into the codebase. So the C in CPython stands for well C right the C programming language. So uh CPython is mainly written in C. A lot of the well all of the internals are C. A lot of the standard library is C as well. So you don't have to be proficient in C but it's definitely helpful to know at least a little bit because even if you don't work on the parts uh even if you only work on the Python parts you will come across you know a lot of C code just just because it's in the same project. So it's also helpful to know a little bit of C as well. And so where to go from here? Uh so the best thing you can do if you are interested in getting involved with the project is to join us for the CPython sprints tomorrow and on Sunday. Um I'm going to be there. A lot of other core defs are also going to be there as well. And really the whole point of the sprints is to well be there for you, help you get started, answer any questions you might have and we're also going to have some beginner friendly issues for you to work on as well. So definitely come uh check it out if you can. Also check out the Python dev guide. There's a lot of practical information things like how to compile CPython locally, how to run the test suite, lots of other things as well. So check it out too. And then lastly, but most importantly, uh just take your time, right? CPython is a very large project. Uh like I said before, it can get quite overwhelming, especially at the start. So just take your time you know try to absorb all the information at your own pace and you know there's no need to rush into anything. The project is not going away anytime soon. So yeah just take your time and yeah uh that's all I have. So thanks a lot for listening to this and um if you have any questions about CPython core development or mechanical keyboards I'm happy to answer. And yeah that's all I have. >> [applause] >> Okay. If uh if anyone has any questions, there are microphones here and here. >> Thank you for your talk. I was wondering regarding the the the graphs you showed if you have any idea either concrete numbers or just a rough idea of how many contribute well lots of contributors never make it to triager and I'm assuming some triagers remain triagers if you have any numbers on that. >> Uh not off the top of my head but I think for triagers specifically I think very few remain triagers for long periods of time. Typically the idea is once you actually become a triagger the idea is to really get you to a core developer eventually. Uh for how many contributors never become triagers? I think quite a lot because a lot of people just contribute one thing and then they go away. Uh but that's just kind of how it happens in a lot of projects. So I don't have the numbers but it's going to be a lot for sure. >> Thanks. So looking at the GitHub repo um for CPython, there's obviously a lot of issues open um how do you go about kind of picking a new issue to work on or like like picking an issue? How do you know kind of there's a good chance that a PR for that issue would actually get reviewed and picked up? >> Uh do you mean as a new newcomer to the project or somebody who sort of >> as like yeah as like a new contributor? >> Yeah. Um so there's this there's there's the easy label on on GitHub for issues but to be honest a lot of the issues are first uh once you give it the easy label people just you know are looking for it so it's usually they are always taken so uh I would say don't look at the easy label anyway because it's it's not useful to find things um yes it's in the beginning it's very hard to find things to work on is true because a lot of the issues even now when I myself when I look at issue tracker a lot of issues I have no idea what they are about and I wouldn't even know where to get started. So I mean it's it's a really hard problem. That's why I say if you can come to the sprints because there we will specifically have some issues that we know are beginner friendly and you can work on otherwise just look at the issue tracker maybe spend some time on it just kind of get familiar with the kind of issues that people open uh to get an idea of what gets worked on who's doing what and uh you know eventually you will see something right it just requires some time is true especially in the beginning you might not find something right away. >> Sure. >> Excellent. >> If I could uh add something there uh if you don't mind. >> Of course. >> Uh I would say definitely look at the dev guide. There's a lot of uh discussion there about how to get in and don't be afraid to start asking questions on uh either you the discord server or the uh discuss. And um a really good thing is to maybe find an area that you're interested in and uh find one that um other people aren't as interested in and maybe focus on that. There's definitely many parts of the library of the standard library particularly where at the moment nobody's really active on and and that's why PR started accumulating and can really make a big difference that way. >> Cool. Thank you. >> Hi, thanks for the talk. That was a lot of fun. Um I'm someone who likes to look at other people's code. So, I I would love to review stuff, but as someone who's never contributed to it, like how much does my voice actually like move things along? Like if I review something as just a drive by reviewer or you know, I would say quite a lot. I mean, obviously if you just go on the PR and you you write LGTM and approve doesn't doesn't have a lot of weight. But if if you actually, you know, review PR, you find issues with it, you suggest, you suggest things or you find things that don't work, that your voice counts as much as anybody else's in in that regard. I would definitely recommend again checking out the dev guide because I think there is some section about how to review PRs. There are some tips. Uh but in this regard, I mean, your voice counts as much as anybody else's. So yeah, definitely, you know, check it out. >> Thank you. Okay, perfect. Anyone else? All right. Well, then how about a big round of applause again for