EuroPython 2026 - Python Steering Council Update

Good morning everyone. >> [applause] >> So we're the the Python Steering Council. I don't think we've ever been at EuroPython in quite these numbers because this is 4/5 of the entire Steering Council. Uh so I think this is the first time we have a Steering Council panel at EuroPython, but it was overdue. So uh we'll start with some introductions. Uh >> Oh, you go first. >> No, no, you go first. >> Okay. My name is Dong-geun and I'm the Steering Council from last year with the amazing colleague in here. And yeah. >> Yeah, so I'm Pablo. I come from London although from the accent you can say that probably I was not born there. Uh and I've been in the Steering Council for 6 years, I think. >> Um we don't have our slides up, but I don't >> Yeah, we we have a slide. If you want to show the slides. >> Magic of the slides. Wow. >> Um >> [applause] >> Uh I'm Savannah. Uh this is my first year on the Steering Council. Uh I live in the US but I am Canadian. >> [laughter] >> Yeah, that deserves applause. >> yeah. Just in case anyone was wondering. >> Because of your first year on the Steering Council, right? >> Yeah, yeah, yeah. >> Um my name is Thomas Wouters. I'm from Amsterdam in the Netherlands. I've been on the Steering Council uh I've been on the Steering Council 6 years but not continuously. And then I will also mention Barry Warsaw who's not here because he's American. Uh he's been on the Steering Council I think 5 years but also not continuously. >> Oh, yeah. And I forgot to mention I'm from South Korea. Sorry. I am too nervous now. >> So um actually I will also mention we all work at different places. We all kind of work in the tech industry but uh that part is a little diverse as well. Uh, >> There's two buttons and you press the wrong one. >> [laughter] >> Yes. Well, there's three buttons. I didn't press the wrong one. >> Oh, okay. Okay. Three buttons. >> [snorts] >> So, what does the steering council do? Uh, the steering council was made to replace Guido when he decided he no longer wanted to be the benevolent dictator for life. Uh, he mentioned this yesterday. I don't know if everyone was, uh, watching the uh, podcast recording. There was a little bit of a kerfuffle, uh, around the walrus operator and he realized, uh, he didn't want to do this anymore. So, we, uh, the Python the Python core dev community came together, discussed how to replace Guido who had been doing that for like 30 years. Um, and the answer was obviously five people. So, uh, I will tell you five people probably still not enough. Um, the uh, steering council is elected by the core dev group, the core team, from people who run who are nominated by the core team, but not not necessarily part of the core team. Uh, however, everyone who's been on the steering council so far has been from the core team. Uh, it's just not required as part of the process. Uh, the main purpose of the, uh, steering council is to do the technical leadership of Python of the language and assume the authority that everyone wants, uh, there to be, you know, the the final say on PEPs, the final say on packaging, the final say on, uh, how the core team should be, uh, organized, uh, the veto on new core team members that are proposed and voted on. Uh, and And that's what we do. And we're also supposed to uh, do all of this by consensus. So we need to seek consensus among the community and not just push our own ideas through. And trust me, we have a lot of ideas of our own, but we do take care to both see what the core dev team thinks and also what the larger Python community thinks and what we need. We also do a little bit of the technical direction of the developers in residence who are paid by the PSF to work on Python itself. And we generally spend PSF money on Python development. So we spend a little bit of money on like documentation integration and tracking. We spend a little bit of money on various different like the GitHub migration when we move to get up issues, that kind of thing on a project basis. The main thing we spend money on are the developers in residence and then we also host a or we fund basically fund a sorry a core sprint for the core team once a year where we all come together for a week and really deep dive on Python development. And all of that needs money. So we also help the PSF do a [clears throat] little bit of fundraising, although not as much as we probably should. So the developers in residence are the project started in 2020 2019. Uh where we wanted to hire people to work on Python itself and at the time Google came along and said hey we want to donate a bunch of money to the PSF to support Python and we put that money in the development residence program and hired Lukasz as the first one and then a couple of years later or a year later Meta took over that sponsorship. Only wanted to do it for 1 year. Meta took over. Meta's been sponsoring that position since then. And then Bloomberg also stepped up and Vercel stepped up last year. So, we have three developers in residence. However, Lukasz decided he didn't decided he needed to move to Canada. He wanted to move to Canada. And because of that, he could no longer do that work. He needed a corporate sponsor. So, he now works at Meta, but not because he was developer in residence. I was part of the hiring process, so I can assure you no hanky-panky there. But, we do have a vacancy now. Um the we are going to fill that vacancy. We just need to, you know, get our asses in gear. Uh there will be three developers in residence. There may be more because there is room for growth there as well. We just need money, right? So, and it doesn't have to be one big sponsor. Like like I said, specific companies have sponsored the specific roles in the past, but it's not a requirement. And if you have ideas of what we can do to fundraise money for those positions, you should talk to us. If you have ideas of what to spend money on for Python development, you can also come. >> We should fix the name of the development itself. We should fix the name of the developers in residence because you see, when Lukasz was there, Lukasz was a developer in residence. And then there was a deputy developer in residence. But now that Lukasz is not there, the deputy is to no one. Like this >> We also need to hire someone. >> The city of the city of developer in residence >> We need to do a lot, Pablo. >> Okay. >> [laughter] >> So, I mentioned the core team sprints, the annual event. This is a picture from last year at ARM. There's usually a corporate host. This year it'll be Open AI. And we alternate between Europe and the US at least we try to. So we don't know yet where we're going to be hosting next year, but there are some some ideas. And that's a really productive time. It's usually right before around the time the final Python release is prepared because we have a an annual release process. So there's a lot of bug fixing and then there's a lot of preparation for the next Python release. So if you want to support the development of Python itself, we do that through sponsorship of the PSF. You can donate to the PSF as well. You can donate directly to the CPython project or you can donate to the PSF in general and then some portion of that goes to Python development of the language. So now >> Are you still your it's my turn to mess up the big clicker. Okay, Python 315 is nearly here. Are people excited about Python 315? Anyone? >> [applause] >> We're going to talk about some really cool features that are landing in this release. Pablo, do you want to talk about lazy imports? >> Why me? >> Why you? >> Okay, yes. So lazy imports is is is very cool. So as you know, like this is a like it's the second round of this because the steering council asked included we rejected the first round and then here's the second round. Now now much better. So you know, the idea here I mean it's a complex feature. So we we don't have time to just go over the entire thing, but the idea is that now there's a new keyword called lazy that you can put on your imports and then it will not import at the time you know, that the import is declared. It will only actually trigger the thing the first time you use it, right? And then the cool thing about this is that it will help with many many things. I mean the purpose quite extensive, but you can expect things for you know, if you have ever have a CLI in Python like a source CLI and then like you do that that help and it takes like an hour to just show you the help. Perhaps not great experience, you know, like something can be improved there. And the reason, of course, is that because that is going to import half the planet. So, with lazy imports, you will only use actually what what is required. And that's one example when this becomes very useful. But it's not just about time. Like, for instance, importing everything if you don't use it like requires a lot of space as well, so memory. And this helps with memory a lot. And it's not just about CLIs. Like, for instance, Meta has a very famous post about like all the improvements in Instagram just because of the original version of lazy imports. And HRP, for instance, has a fork based on the Meta one that actually help a lot with our our use cases. So, now we hope that, you know, it was a very complicated feature to get in because, you know, there's a lot of nuances. But in Python 3.15, you can now just use it. And hopefully, we hope that you will enjoy it a lot. >> Yeah, frozen >> dict. And now we have our frozen dict, so you you can now you can create frozen dict and you cannot modify once you create it. So, now we have a tuple, we have a frozen set, and we have a frozen dict. Please enjoy. >> [applause] >> Wow, applause for frozen dict, but not for lazy imports. Wow. Just I mean, Pablo and I worked on lazy imports, so that that feels that feels like a personal attack right there. >> [applause] >> Uh Py Oh, lazy with clapping. Uh Python 3.15 is the most colorful Python yet. I think very many of the standard library modules now have colors thanks to largely to Hugo, maybe. I don't know. Lots of people contributed to this. But you should see it in all of your favorite packages in this coming release. >> On your own packages, right? Because our also allows colors. So your CLIs will have colors if you want. >> It's true. >> Wow. >> Applause. >> [applause] >> Ah, yeah, this is very cool. So so in the Yes, of course. Yeah, yeah, yeah. In the the new the new installment of Palomax did another profiler. We make a a huge profiler in the standard library. In fact, it's so big that the European Union will probably regulate it soon. >> [laughter] >> Whoops. It's illegal in certain countries. You can only use it in Germany in highways. That's how fast it is. Yeah, but anyway, so so it's a it's a new sampling profiler in the standard library. It's called Tachyon. But they didn't allow me to have a Tachyon module, so now it's in this new like replace module called profiling. So you can go to profiling.sampling and then the old CProfile is now is profiling.tracing. Also, you can use it as CProfile, but but it is very annoying because you know, CProfile is CSub like the PSub. case and nobody remembers that. Anyway, so now you have a super sampling profiler with like a ton of output. You can like read flame graphs. You can see live your processes. You can attach to running processes. If you have a process that is hanging, you can also like take a snapshot of that to know what is going on. You can also for the first time this is the first profiler that can also sample async IO. So like you have like Thanks to actually someone. So you have a bunch of task. You can you can see like you know, what async IO is doing looking at all the hot task hierarchy. If you have a bunch of task waiting for IO, you can also see that as well. So you can see everything the thing that is happening. So for example, you're using FastAPI, you can see like all the all the different requests happening and who's calling that, which is very cool. And it can sample to 1 million samples per second. Very impressive. And it also works with free threading. Very cool. >> Has a really nice UI, too. >> Yes. >> [applause] >> Uh and and you can't read like this at all cuz it's like the smallest font ever, but that's kind of the point. There's a lot of features in Python 3.15. Um and so you should definitely read the what's new and read all the cool things that are coming to the next version of Python. Um let's see. Oh yeah, and this is my plea for you to go and try out the latest beta. Uh beta 3 is out now. Release candidate uh one will come out in August and then uh 3.15 final in October. Please try it out. Tell us where we've broke things. Uh bugs are gifts. Uh so please file issues. Uh and then as the release manager for 3.16 uh I want you to get excited about 3.16 alpha one that starts right right after 3.15. A little bit early, but uh yeah, get excited, I guess. >> [applause] >> Okay, I need you to control this cuz I'm going to read the questions. >> So now we have a Q&A. Um so we Well, ah yeah, yeah. Okay, so so so we want to hear from you. So there is a Discord No, we are still taking them from there. So there's a Discord channel uh where you can put your questions. We'll read them. >> There's a thread in the in the general chat in the Euro Python Discord server. Um you can There's some questions already, but if you have other ones, like we'll get to them. >> And there's also mics for the people in the room. So you can walk to a mic as well. >> Well, in case you are all shy, we did the stupid also thing to like like have some stupid AI questions. Uh they are so stupid. Uh and we wanted to >> [laughter] >> We wanted to share it with you. Like like here is a bunch of examples of a stupid AI questions. Uh my favorite one is this like >> [laughter] >> My favorite one is the the first one because it's like oh, you know, would you rather fight a duck-size in a py or 100 chicken-size in a py uh We actually generate an image of such a thing, uh which is so stupid because both are the same size. Like [laughter] Stupid AI. Anyway, uh just give us good questions, right? Like this is the This is the bar. It's very low. And I'm going to leave this here, yes, just for uh you know, spice spice in the room. >> The bar is very low. >> Yes. Shall we start with one from Discord? >> Yes. The first question uh is what is your favorite part of being on the steering council, and what is your least favorite part of being on the steering council? >> I can I can tell you what my favorite part is because it's also probably Barry, Dong-hee, and Savannah's least favorite part of being on the steering council, which is me arguing with Pablo. >> I mean, it it is a regular occurrence where like I'll look at Dong-hee and Barry and be like, "Do you guys just want to leave for a bit and let them like hash this out?" And uh all in good fun, though. >> Yeah, no, no, all good. All good. >> yeah, yeah. >> Yeah, Pablo and I get along great. We just uh like to argue, both of us. >> Yes. >> What's my favorite part? I think um maybe like a misconception about CPython is that every core dev works on every area of CPython, and so prior to being on the steering council, um like I knew about what work was going on, but I think being on the steering council lets me have like a nerdy research project like once a week whenever someone on the team submits a new PEP, and then I get to go and like deep dive into some new area that I haven't worked in before. I think that's like very fun and interesting. Um so yeah, that's probably my favorite part. >> I think my favorite part is that's like solving really complex problems together with with with people and friends. I think that's that's what I like the most, like which is also kind of my least favorite part because like some of the problems we need to solve are like quite like, you know, difficult >> Social dynamics. >> Yeah, yeah, yeah, the social dynamics. The because like, you know, we need to like the the the rule of the steering council is that you cannot win, right? Like so you you need to choose between like many of the times two things that you actually don't even like or tell friends that their PEP is not accepted and things like that. And that, of course, you know, is is the good for the language, and that's our job, but like can be quite quite heavy. Um so, yeah, that that's probably the part that I enjoy less. >> Yeah, so my favorite part is that I can participate at very difficult technical discussion with with amazing people, and I can also give a different view that I have. So, that's that's all of the my happy point. And I personally even grows that because I can cover that that I never have an experience before, but now I have experience to to to read a episode. That's a good thing for me. >> Uh shall we take one from the audience since we have someone over there? >> Sure. Let's do it. >> Hello. Uh first of all, I'd like to thank you very much for all the work that you're doing on Python. So, um um yeah, my thanks for that. Um question I have is um first of all, I'm going to assume that the work that you do on the on the steering council is uh very much independent of like the work that you do for the for the company your respective companies. Um but I can imagine there have been instances where uh your company said like, "Hey, we would like you to advocate this thing of our own Python or advocate that thing." Have there been instances of that where you felt pressure from your company to do something that you may or may not uh be uh uh uh behind. >> Um I'll start because I think my company's probably the one you would most think of as putting pressure on me to get things done because for instance like >> Thomas? What company? >> It matter. >> [laughter] >> Facebook. Uh I mean, Facebook's been in the Python community for a long time, but hadn't really been that active in core development. Now, we have a whole bunch of core developers working at Meta. Um the the company doesn't tell us what to do on core development at all. Like, I want to make that entirely clear. My manager doesn't, my director doesn't, all the people above me don't. If I if they did, I would tell them no. Um I worked at Google for 17 years while I was a core developer, also while while I was on the steering council uh they never asked me to do anything but if they had I would have just said no and I mean the worst they can do is fire me so try and fire me I'm I'm from the Netherlands I I'm not from the US I'm not worried about getting fired. So >> [laughter] [applause] >> I I think I think one good example of this as well is that like we you can actually see how we actually often take decisions for the language that are extremely against the you know benefit of our own companies. Like one example for this I would say that actually affect both of us is lazy imports right? Both meta and HRT have a fork for lazy imports based on the old idea and then we did the lazy imports in a way that works for everyone with the community feedback in a way that you know doesn't involve hacks and whatnot and this actually goes like it affects both companies because we now need to undo the previous version and then do the new version and do a huge migration uh which probably at meta is much worse sucks to be you uh but like but but you see like this is a good example right? Like we we we want what is best for the community and we want to do these changes to also incorporate things from the community and and the PEP not only you know has the the the ideas that we have that um we knew that it was going to be better but also like a bunch of things that people wanted and that actually goes against the you know first order benefit. You can argue that of course uh you know in the long run these companies will benefit more from you know having to maintain their own versions but like in the immediate you know future uh like it's it's a problem and this happens constantly. The other thing I wanted to add is that we are five right? So even if this will ever happen with one person uh like you have four that are still you know don't have any benefit in that sense if you are like extremely negative about the you know involvement of the steering council but like we we will check each other very soon. And the other thing I want to add is that by the steering council charter um they can only be two uh people from the same company max in the Steering Council precisely to control the background of this. So, I think that's This has never been a problem, but even if you are very paranoid and you are like your tin hat kind of thing like uh you know, it's it's it's checked out and like it's very controlled. >> I think there there's another backstop which is uh the Steering Council can be basically recalled by core devs. So, if anyone else thinks that there's something fishy going on, uh there's more remediation possible. >> Also, we don't vote on our own PEPs just to make that clear. Like if you author a PEP, you're not part of the the deciding body. So, that's more in a general sense, but yeah. >> Yeah, uh Pablo and Savannah had a PEP earlier this year and it was so uncontroversial that it took Barry and Dong-Yuan me I think 5 minutes to I mean I mean I was already for, but we still discussed it for like 5 minutes and accepted >> We we take this seriously. Like when I when I have a PEP of my own, I always offer to go out of the room. Yeah, so in case like they want to discuss something without me and the same for everyone. So, we we take those things very seriously in that sense. >> Another Discord question. >> Uh do you have any personal learning since being on the Steering Council which you may not have expected before? >> [laughter] >> Personal? >> Any personal learnings like >> Uh personal learnings? People are hard. Like >> I mean >> I was on the PSF board for like 5 or 6 years before I was on the Steering Council and nothing surprised me. Uh I mean, it's it's very different work, but the surprising things about people, they're all the same. >> I mean, maybe this kind of dovetails with another question that's in the chat about what the Steering Council's role is in in the Python community. Like broader than just the technical decisions, like do we talk about the people stuff, the community stuff that aren't peps? And the answer is yes. Uh like the project's health is more than just the code that goes in the code base. It's also the people that come back to the project, you know, day over day, week over week, year over year. Um and so like we want those people to be happy and healthy and wanting to maintain the stuff that they maintain. So that's absolutely part of what we talk about. >> I will say it's almost as much as the peps or even more. Like we we talk about all sorts of things that are not immediately like related to the peps. Like for example, like there's been like like lots of lots of talking about not only the let's say free threading, right? Like not only free threading by itself and the technical aspects of free threading, but like how how to maintain it, like how to ensure that like this is not really hard going forward and we don't shoot ourselves in the foot, like how like every even every feature and every pep we we approach it from different angles, right? Like what if you are an educator and you want to teach this like it doesn't matter or like what if you are someone in like this happens all the time. Like who benefits from this? Like who will use this this kind of thing? So so this happening all all the time. >> I mean I think we also talk a lot about like mentorship and like discussion health on discuss.python.org and like various other factors. How do we get new contributors into the project? Like what are the challenges we face there? Um yeah, Don G, were you going to >> Oh yeah, I know so that the technical decision is pretty easier, but like people issues is tough and sometimes we we send the message, but sometimes people interpret that what that what we didn't want. So that kind of thing is very tough. Yeah. >> Yeah, communication is hard. Yeah. >> We're really >> Oh, we're >> angry timer at us. We're >> [laughter] >> We're 10 seconds over and it's like >> Well, do do we do you want us to stop or should we keep going? We can keep going for another half hour. >> [laughter] >> They're like, please stop. >> break. Coffee break. People want their coffee. You can ask us questions later. [laughter] >> For >> [applause] >> What further people on Discord, uh, will answer the questions asked on Discord. Uh, and if you're not on Discord, maybe that's a reason to join the Discord. Thank you. >> Thanks, folks. >> Thank you.