EuroPython 2026 - CPython Panel

Greetings to everyone. Welcome to the C Python Core Developer Panel. C Python has evolved a lot over the past few years , thanks to the contributions of many people who have brought new ideas and perspectives and overcome many challenges. So today we'll discuss where Python is headed, how these ideas are turning into reality, and how anyone can get inspired to shape the future of Python. But before we begin and take questions, I would like the panelists to introduce themselves. If you could briefly tell us who you are, how long have you been contributing to C Python , what aspects of C Python are you working on, and what is the most exciting aspect of this project right now? Do you want to start first? Of course. Yes. My name is Eric Snow and I work on runtime internals. I've been contributing to Python since probably 2010 , working as a committer since 2012. I am very excited about the impact Python is having on our community and the technology world. Hi, I'm Kengen. I have been a core developer since August 2021 and I love working on controversial topics. I am Peter Burma. I've been contributing for about two years and working as a core developer for about a year. I mainly work with the C API and the Python runtime. And speaking of excitement , it was pretty good until the steering council shut it down. I am Alex. I've been contributing to C Python since probably 2021 and became a core developer shortly after that. I mainly work with typing and documentation , and yes, I'm Mark Shannon. I started working since 2011 , but I didn't become a core developer until 2018 because I was a bit lazy and there was n't a good CI system back then. So I didn't want to go to the trouble of downloading the patch and testing it myself. If by exciting you mean scary, then that's free threading. In my opinion, this is free threading. And if by exciting you mean something fun, then it's quite enjoyable to work on. Working with JIT spores, but currently there is an opportunity to do some cool work with GC. I am Yuri Salvanov. I am a sleeper Python core developer. I joined this position in 2013. My most exciting contribution is probably the async await syntax. And my initial work with async.io. Recently I've become interested in ruining the typing system for everyone. There is PEP 58 there. Pep 827 , which I co-wrote with Michael Sullivan. If you have n't seen it, check it out. Okay. Thank you. Well, I would like to ask a question at the beginning of the discussion. Cython has changed a lot in the last few years, and these changes are happening much more frequently than they were 10 years ago. So the question is, what are the differences today compared to 10 or 15 years ago ? What will someone say? Yes, now free threading has arrived. Anything else ? Now, when implementing something, you have to think about thread safety. Okay. There have been many changes in the composition of the core team, the size of the contribution, and the number of contributors. There have been changes to the PEP process. You know, we used to have a BDFL , now we have a steering council which has changed the dynamics there. There is now a lot of emphasis on community consensus when it comes to change. Python's codebase has become much more complex than before. And with the development of Python in the world of technology, various trade-offs have had to be made. Does anyone else have any older opinions ? I think the biggest change since I joined the project was the move from bugs.python.org to GitHub, which has greatly increased the accessibility of the project to outside contributors. And also for the outside triagers. Now we are clearly in the age of AI , and perhaps we have gone too far down that path , which is why we are now struggling to handle the PR and issues sent by AI bots. So where to draw this line is an excellent question. One of the big changes I've noticed is the increase in its size and the amount of money involved. A funny example is, when I first went to Python conferences , people would say, "I work on Java during the day , but I come to Python conferences because I love Python." And now I hear people at conferences saying, "Yeah, I don't really like Python that much. " "I want to program with Rust or something , but my employer makes me work with Python." So, this is a really interesting change. But the good thing is, now there's a lot more money involved. I don't know exactly how many Cython core developers are working full-time on a paid basis, but I think there must be at least seven. Maybe close to 10 people , but before there was n't even one. Well, maybe there was one. Guido probably always got paid for it, but that number wasn't much higher than in 2010. Yes, there were very few people then. Okay, great. Before asking the next question, let me say something. We have two microphones. There's one there, and there's a microphone there for people far away , because you can't come down. So if you want to ask any questions , go there; I also created a thread on S2. On our Discord channel. You can type your question there and I will monitor that thread. So if you want, I will ask the question. Eric, you mentioned earlier the transition from BDFL to the Steering Council. In fact, while talking to someone this morning, I got feedback that Python's trajectory seems to be a little different since that change. Do you feel that way because you've been here longer than many in the community ? I think there is a difference. I would n't say it's bad. It's just different. I think it's only natural that such changes will lead to variations in the workflow , especially when the consistency decreases slightly from year to year. Hmm. It doesn't matter who is making the decisions , but I think the steering council now has much more responsibility than Guido. Yes. Many additional features have been added to the core development. Python is also now in the next phase of its life. So it changes the dynamics of the content and the steering council is very aware of that, and with that in mind, they are a bit cautious in making decisions. Okay, thank you. Does anyone else want to comment on this? What do you think about the trajectory of Python technically since the change from BDFL to the Steering Council model ? Anyway, this transition was very chaotic, but in the end Python is much bigger now. And it is being used in more cases than ever before. 15 years is not an ordinary thing. And I think Python has now reached a point where it's not possible for one person to handle the whole thing alone. So I think it was ultimately important for us to eliminate the differences and the bus factor. No matter how it happens. So I think it's a natural process. Okay. Thank you. Is there anyone else? I can't really see. Yes, there is someone. Yes. Start. Just now and this morning, you talked about community consensus, and I was reminded of a quote by Henry Ford. He said, when people asked what they wanted, they would say fast horses, but we got cars. So you are certainly not asking through a referendum whether we should accept the APE or not. But if you do n't, what's the point of getting community consensus? How much consensus? What does this mean in practice? And do you ever go against that, sorry? This is exactly what I wanted to know. I think the steering council wants the consensus of the core developer community rather than the wider community, but perhaps they will take that into account as well. However, it is better to ask the steering council about this; Some of them are right there. From my perspective, there is no single community for Python. For example, FastAPI community, NumPy community, etc. So what the steering council usually does —if I'm not mistaken —is that when there's a change proposal related to typing or the scientific community, they try to get feedback from the people involved. Finally, it is hoped that the Typing Council knows what the position is on typing and that they can convey that opinion to the Steering Council. That is, the opinions of all communities ultimately flow upward. Okay, thank you. We have two questions from Discord. I'm saying the first one. If you could wave a magic wand and make any change to Python without any consequences— even a breaking change—and all users would accept it like magic, what would it be? I know what you mean. No, no, no. It's not what you think. I would change the C API. Yes. So, it's nearby. Yes. Let's give some context: The C API is what allows C extensions like NumPy or pandas to communicate with the Python interpreter. I'm not belittling anyone by saying the C API is bad or anything, but I think the new API could be much better with what we've learned from Python over the last 30+ years , and if everyone could make changes to it , that would be great. Yes, this is my magic wand. To say more about this. Especially the issue of borrowed references in the C API. For those who don't know, Python uses reference counting. And when functions in the C API return an object, they usually increment its reference count. However, there are some functions like pi-list get item, which is used to get an item from a list. This returns a borrowed reference , which means you are reusing the same reference that is already in the list. So if someone in another thread deletes that list , that reference becomes invalid and you encounter a 'use after free' error. Oh, your magic wand is very conservative. I want everything, not just that. You can break everything. Yes. I want to break all of these. Yes. Okay. Wait. No, do n't capture it on camera. Sorry. I'm saying this mainly to see Yuri's reaction. I think the way async works is, we started with generators and added different parts to them, then came co-routines which have additional debugging features, and then tasks were added on top of that, and so on. I think Java did it right, because Java saw the work of others and since Java was very slow, they were able to make the right decision and move towards virtual threads. So I want to eliminate all async mechanisms and replace them with virtual threads. Okay , it looks like I have 46 minutes and 5 seconds. To give the correct answer to this. My personal opinion is that there is a reason why programming languages without the GIL have async- await , even in languages ​​that do n't have threading problems like ours. And that reason is readability. I fundamentally believe that humans are incapable of writing proper multi- threaded code , and I certainly ca n't. And I think async- await makes that a lot easier. So, maybe we should do a separate panel, just you and me. In a ring, and then we can discuss it. I can leave if you want, I'll leave it at that. If I had the chance to change one thing in Python, personally, maybe this will sound controversial, but I would make all strings act like F- strings. That is, the F prefix or prefix was not needed. Okay. Any other opinions? Any other uses for a magic wand? I am talking about a small matter. Okay. Maybe how to write an empty dictionary. Hmm. So that empty sets can be written with curly braces, and empty dictionaries... yes. I don't know. Something else. Yes. Maybe square and angular brackets. Okay. Shall we go next time or not? Well, oh, I mean it's not a very controversial feature actually. I'm still not a fan of the Walrus operator. I mean, I wasn't a big fan of type checkers before I wrote them , but when you write a type checker, it's hard to overstate how many strange situations it creates. You can tell how many rules it breaks, where you say all definitions are associated with a statement, except for definitions made in the walrus operator, and all definitions are associated with its local scope, except for definitions in the walrus operator. Okay, thank you. Is anyone standing there? Yes wave your hand because I ca n't see anything, yes start. My question is, some tools are written in Rust. I'm thinking about Astral's UV, I'm curious what you think about it, do you use it , and does it bother you that so many important tools are written in Rust instead of Python ? I like it. Yes, I work on the Astral Team, so I think I should refrain from this discussion. I'm primarily a C programmer, so I do n't use it. I think the tools written in Rust are great. Extensions written in Rust are great. We are thinking about writing some parts of C Python in Rust, and are also experimenting with it. Therefore, Python has always embraced technologies that make sense for the community. So if some parts of it rust, that's great. Yes. I don't care what language your tool is written in , as long as it works. We try to make it work. Right. Thank you. Is there anyone else? Yes. Yes. Start. My question is about garbage collection and the magic wand that can change anything. About free trading. Have you considered using the concurrent mark-sweep method instead of the reference counting concept altogether, which seemed crazy 20 years ago but was successfully done by the Go language people? Have you thought about this? We thought, what do you mean ... yes. Mark and Sweep. The problem with Mark and Sweep is that you have to collect everything together. So you need incremental and generational approaches and everything becomes increasingly complex. Reference count gives us instant reclamation or recovery facilities in many cases and many things depend on it. For example, all the huge tensors in NumPy need to be reclaimed very quickly. If there are hundreds of such things lying around and each one is a gigabyte in size, that will become a big problem. Especially if they use GPU memory or any other specific resources. There are many C APIs that rely on reference counting behavior. They hide the reference count in such a way that there are no real references anywhere. This is a kind of implied reference or reference to something else, but the reference count is explicitly incremented and then decremented. The C code is correct, but even a C heap scan with a conservative collector might not find everything. Yes, this is a big change. I mean, even with a magic wand and vast resources, maybe there are better performing collectors, but I don't see any way to get there from where we are now. I understand. Thank you. What I meant was , reference counting is very useful for wrapping C++ libraries, like standard shared pointers, because that is also reference counted and changing it to something else would be much harder , and we want Python to be extensible. Oh, and another thing in favor of reference counting in free-threading Python is local references. Most objects that are created and lost are local objects that are created inside a function and used during the function call. They have very limited scope, so having local reference counts between objects, I mean, okay, this is a little... this, this, this, this is even faster. This is more efficient, because as you said, the references go away very quickly. It's a little complicated, okay, it's like different levels of ref counting, but it's also pretty good to have for free threading. I'm going to the next question on Discord. What advice do you have for preventing PEP discussions from turning sour ? As pep writers, should we actively steer the discussion, or should we let the discussion flow naturally ? What should be done when people who have no responsibility control the discussion ? There are many questions. Yes. About the pap process. We were saying earlier that we want community participation and representation. So I do n't think we should filter or limit our discussions. If there are thousands of comments, it will be quite uncomfortable for the person who has to filter them. However, you can use AI Summary if you want. Anyone else have anything to say? I agree with Mark. I mean, there's a lot more engagement in the pep talks than there used to be , but I do n't know, at least in my experience, the discussions haven't gotten too heated. Do you see any patterns in the opacity of different Peps ? I mean, in terms of the content of Pep. I have my own opinion, but there can be different ideas about different perspectives and approaches. Yes. And at the end of the day, everything depends on resolving those differences and making the final decision, which rests with the decision-maker on the proposal. So, basically that's the most important thing, reaching a conclusion. Decision. Yes, I agree that we must allow people to have free and frank discussions and allow everyone who wants to contribute to do so. I think in some cases the pattern is such that the discussion tends to wander, especially in the case of hot topics. I think some moderation or control is needed in those situations. In this case, you are not censoring anyone, because people have already said what they want to say. I think it's just an attempt to defuse the heat and give a voice to others who may be feeling overwhelmed by the pressure of the discussion. Yes, I think moderation is definitely effective. I think it's important to distinguish between people and their ideas. It can be difficult to separate yourself from your own ideas, but it shouldn't be difficult to separate others from theirs. Yes, any criticism of the individuals involved should be stopped quickly, but everyone should have the freedom to criticize ideology. Okay, I have another controversial question. Out of curiosity , would you give a different answer than the Steering Council? What are your thoughts on the recent major experimental changes to the language, such as free threading and JIT? Would you like to see more or less of this kind of change ? What changes would you like to make to this process in the future? Yes, contrary to what I said earlier and popular belief , we do not experiment with C-Python for the sake of breaking it. We do this because we believe that language needs to evolve in certain ways , so we experiment and continue if it succeeds. What needs to be changed? In fact, there are many disagreements about whether C-Python should be constantly evolving or stabilized ; But if you think it needs continuous evolution, then we need a better system for running tests in C-Python. This is an open question, as most mature languages ​​have more than one way to do this. So I'm not sure. Yes. Can anyone else say something about this ? Tell me. Actually, I have many opinions on this , but basically we should have complete freedom to try new things. If we run the test on the main branch, it might not be right. Python is no longer at the point where what was meaningful 15 years ago will still be. It does n't work like it did 15 years ago, right? But we have to be careful in considering the impact , which we do, and I think we sometimes get a little too conservative , but that's probably the right thing to do. But as long as we're trying new things and seeing what works best for language users , that's fine. Okay. Thank you. I think there's someone standing there. Tell me. Hello, thank you all for coming. My question is, what has the C-Python team learned about increasing diversity and what are the most difficult problems ? Difficult question. I...so as a core team we worked on this , but we didn't get very good results. That is, there is still a lot of room for improvement. I think everyone is aware of the importance of diverse groups, different ideologies, and people from different backgrounds. But it's easy for a group to remain homogeneous, especially because of human nature. Therefore, it requires active effort. I have seen that it takes active initiative to change this. We can't just talk. This requires personal work, because it is really difficult to enter a group from the outside. This is very uncomfortable. This is a challenge for most people. So usually it's the people inside who have to pull others along. Otherwise, you will only find those who are not hesitant to mingle with new people. This has become a challenge for us as the main team. Guido has challenged us on this issue in the past and set a good example, and we have made many strong efforts to increase diversity. But it's hard to hold on to. I wish it were easy. I am always open. I think everyone is open to suggestions, especially those who are eager to encourage and support diversity in our or any team. Yes. In my opinion, the most effective way to bring in new contributors from diverse backgrounds is to mentor them. But the problem is, it's also very difficult to provide mentorship. We do n't have enough people to mentor us at CPython, because everyone is struggling under the pressure of reviews and triage. I was really lucky that at that time I had two wonderful mentors like Guido and Pablo. But not everyone gets it anymore, and I don't know how it can be improved. I know this is n't a good answer, but sometimes it just depends on luck. Yes. Okay. Can I say something about this? Do you have something to say? I can say that I am a little less involved in Python core development than I used to be. From my comfortable position outside of core development, it seems like there are a lot of efforts going on to make Python more diverse in the community, both within the team and outside. My personal opinion is that Python is in a pretty good position as a language. Python's operating system is open to everyone. Ah, anyone can become a Python core developer if they want to, if they put in the time and effort. And I know that Python core developers are always ready to welcome newcomers. Um. It's clear that we do n't work in the same building and are scattered across different time zones. Sometimes, not working full-time or other reasons create communication challenges and this makes the job difficult. But I definitely see that everyone is trying. I haven't met a single person, at least in my acquaintances or other groups, who says that diversity does n't need to improve. Everyone understands that there is always room for improvement , and I agree that mentoring is a very important thing. And I've tried many times over the last 15 years , but it's really hard to mentor someone. It's very challenging to not only promise "I'll mentor you, " but also to answer emails and make time for them even in the midst of their busy schedules when they need help. So, it's really difficult. But it's also enjoyable. I think we should encourage mentoring, although this is where I see the limitations of our work. We know it's necessary, but unfortunately we do n't always have the time to do it. The next question related to this topic is, what is the easiest way for someone to make their first meaningful contribution to this project? Meaningful for the project. Of course, for themselves too. In my opinion, the way to make a meaningful contribution for the first time is to make small or simple contributions first, because you need to build inspiration and momentum so that you can make a big, good contribution later. I also agree with this statement. My first contribution was a very small bug fix in Funk Tools. I think I probably figured that out myself. It was just a change of one or two lines , with tests, it took a few weeks and finally Sir approved it and merged it , which was great fun. This encouraged me to continue working. I think your first contribution should not aim to do something big or redesign the entire language or create a huge API , but rather start by solving your own problems. If something is n't working properly, fix it. I will talk about reviews, because reviewing is a big obstacle now. LLMs can produce code very quickly, but they are not very good at reviewing it. The problem with reviews is that we can understand the quality of the code by looking at it. But when it comes to reviews, it's very difficult to understand how much attention someone has paid or how much thought they have put into them. However, if there is a change to a module that you know well or use frequently, you can try reviewing it. Reviews are a great way to learn how the codebase is organized and what a good contribution should look like. Okay, thank you. Another question about this code. What's the weirdest hack or trick you've added to C Python that you ca n't believe you've made it to the mainstream or stable version? I'm also interested in hearing this. A hack that one of us contributed to. Yes, which has actually been released. I thought this was a very nice solution, for example...when I added 'async await' , I wanted the user not to have to write something like 'from future import async await' separately. So my weird hack was to go to the tokenizer level and check if there is a space after the word 'async' and if there is a word 'def' after that. When this happens, a special boolean flag is set, indicating that 'async await' can be used at this indentation level. And people still blame me for that hack today. Any other hacks? It's not entirely a C Python standard library, but at one point we added a feature to the typing module and had to backport it to a third-party typing extension library. The only way to backport that feature—and that hack still exists—was to use the system's 'get frame' to go up two levels of the stack and check if there was a variable with a specific value in that frame. This is a very disgusting method. Yes, really. Quite. Hmm. Let's now discuss the future of Python. This morning we heard about the features of version 3.15. How excited are you about the changes coming in version 3.16, and I'd like to expand the question a bit and ask about the future. What kind of changes would you like to see in the next five years? We have 24 minutes, so I'll give someone else a chance first. It would be great if it was an operator for non-. Anyone else have anything to say? I do n't want to be that person, but in the end, that's who I am. I want my PEP to be successful and Python's typing to be stronger. So that the typing language capabilities are essentially compatible with the dynamic nature of the Python language itself. So that we can get better and dynamic APIs and reduce the bowlerplate code for fast API code or such tasks. I really believe that this is a good idea. So I will spend some time pitching this idea to the steering council and other key developers. This is going to be great. I might be pronouncing the name wrong, if there is a French person please correct me. Antoine de Saint- Exupéry has a famous quote: Perfection is achieved not when there is nothing left to add , but when there is nothing left to take away. So I think instead of thinking about what to add, we should think about what to remove. As I mentioned, remove all async operations through virtual threads. That is a possibility. The other is to bring parallelism, single threaded, and multiple interpreters into a single model that we can implement quickly and then people can gradually move towards parallelism. Um...and architecturally speaking, better integration of memory management, GC, object model, and other such parts is needed. It didn't take 24 minutes, but I can go into more detail. Sure, tell me. I want sub- interpreters to become more popular , but for that to happen, their current inefficiencies need to be addressed. Which means someone has to solve those problems. Moreover, I agree with many of Mark's comments. I also want Python to expand into more areas. Anything we can do to make Python easier to embed will make a big difference. I think there is a lot of room for improvement in that area. Okay, thank you. One of us is standing there. Yes. There are other open source communities that may work a little differently. Do you see or want to adopt any methods or technologies that are available from these communities in reality or with the wave of a magic wand , or something that you wouldn't adopt at all because it's not a good idea? So, this may be a matter of accepting good ideas from outside or examining and rejecting which ones are good. Does anyone have any ideas about this? Do you have any examples? For example, some things we've always seen in Python were quite open-ended. I think the Pi project toml is probably inspired by Rust, if I'm not mistaken. This Tomcat configuration issue could be an example from a technical perspective. I'm not sure if there is such a thing , maybe there is nothing out there , that's okay too. However, other communities work differently ; Their work style is different. Just like we have a steering council, other communities may have a different model. Do you see anything that is worth considering, or something that maybe wasn't a good idea and ultimately the right decision was to reject it? Well, we took async away, look where we are now. But seriously, I think it happens all the time, languages ​​borrow good ideas from each other. The same applies to frameworks and ecosystems. I think this is a natural process. Uh. This happens completely naturally. Don't let anyone dare mention packaging. I think it's already heading in that direction , because other languages ​​like Rust are an example. Their packaging is included in the language, while Python packaging is something external. That's why our packaging system is so diverse , with things like conda, pip, and others that have evolved over time. And in the case of Rust, I think they learned from Python and made it part of the language from the beginning , which made it much more integrated and simpler. Because in Rust there is no confusion , just use Cargo. In Python you have many options that hopefully will be integrated soon, because installing packaging or stuff is a big part of the user experience, which has been parallelized in Python in the past , this might be an example. Is there an answer, or should we move on ? Like Yuri, I think we will take things as needed. I mean, I avoid the packaging issue. Um. But yeah, I think if something makes sense and if someone is interested in working on it , it will probably be added to Python. Just one thing, it's not that we do n't think about the issue or do n't consider packaging important. The thing is, we are not experts on this subject. Okay. Next question on the core. Many times, big changes are made based on the idea that 'it works on my machine ' , which later causes problems for various distributors or buildbots or those trying to compile with older versions of Autoconf. What is your opinion on this? Is it possible to improve it somehow? One minute, sorry. Did you say autoconf? Autoconf. There aren't many people working in the build system who are comfortable with it or brave enough. So. Someone just needs to come forward. Many people have been talking about changing our build system for a long time. Yes. But it is quite a difficult and complicated task. I think the change I wanted to make to the Python build script, at least on the make side, that could have ruined everything , was to pass GNU make's job server to the subprocess , which Thomas stopped me from doing. Anyway, who really knows or cares? But yes, we are quite conservative in our build changes. If we break something , we try to put it back together as quickly as possible. I don't think we want to intentionally ruin anyone's build. Yes. Question. There are many buildbots. I hope so. We actually have a lot of buildbots. I think no one likes the C-Python build system at the moment, but we're all afraid to change it. It is very big and complex. Could you come to the microphone , please ? For recording. There is a microphone there. Okay. I have a question , not just about the build system, but about all major or intrusive changes in general. Oh, and speaking of buildbots, I maintain 20 buildbots for Python CI. So. Okay. Thank you, I mean thank you for maintaining the buildbots. But can you give an example of a major change that ruined everything ? There could be changes, jets or something like that to increase speed. They are usually not done to destroy anything. But they ruin it. We have CI. So if we make any changes, it passes CI , then it is merged. This makes build bots useless. Uh, usually if it makes a build bot unusable , it's often due to some configuration and needs to be patched again to fix it. If there is a bigger problem, we usually revert. Um, yeah , the problem with build bots is that they're a bit slow. So yes, sometimes it can be quite uncomfortable and it takes a while to revert, but usually they are reverted quickly. Uh, if someone is on vacation, Peter or Sergey reverts things. And we have an answer for me. Yes. Okay, great. Hi, thanks for maintaining the billboard. Uh yeah, I mean I've ruined your billboards several times. Uh, but it's your job, so you do it. Uh, I mean, honestly, if I'm on Mac OS and I make a change and it does n't work on Windows, it's unreasonable to expect every contributor to test on all operating systems. Our build system, you know, is under a lot of pressure right now with the amount of build bots we have for everything. So that's what we have. This is how we understand that any small part of our ecosystem is being affected by any change. And to be honest, the CPython test suite is largely a test suite for the industry; We are finding bugs in many places, including the Linux kernel, Linux, and Windows. So, uh, yeah, I wish we could always submit perfect code, but I think builds are our way of making sure that when they finally stabilize, everything is fine. I do n't think we have much to do with Solaris or the others you're talking about, because very few people have them. Linux is Linux, but then there are things like FreeBSD, which are not very popular. There are actually many more combinations. I think it's not very realistic to expect everyone on this stage to know about all the operating systems we have to support. Okay. Thanks for the answer. Can we move forward? Do we have any more questions ? Yes, I mean Python was once, or still is, a brand whose slogan was ' Batteries Included'. ' Batteries included', but I think there are now many more libraries coming out that are basically the same as the standard libraries, because everyone installs them at the first opportunity. I mean, libraries like Requests, HTTPX , or whatever new ones come to mind. Do you think it's a good development that these things are made outside of the main team , or do you think they should be ' batteries included' or all- inclusive ? Personally, I think this is a very good development. Hmm, libraries used for network requests like Requests or HTTPX require a lot of domain logic that most of the cpython core team doesn't have. We are a large team, but there is still a lot of work to be done on the standard library , which is a lot. I think there are many modules that have at most one or two maintainers. There are many modules that currently have no maintainers. Hmm, and they're usually maintained by regular programmers, if they have the time. I think it's a great development that these libraries are maintained by experts on PyPI. Moreover, it is much easier to provide a new release of HTTPX on PyPI than to fix security bugs by releasing a new Python release. So some decentralization is actually a good idea. I think the standard library should be mainly for low-level batteries, data structures, core algorithms, or perhaps async. IO may be too big for the standard library, but it's already there. Maybe it would be better if it was on PyPI. Um, yeah, I mean, having a library without a maintainer is bad, but I do n't think that means we should or shouldn't remove it from the standard library. This means that if they are in the standard library, we need to make sure they have maintainers. Yes. But code outside the standard library also often loses maintainers and becomes unmaintainable. Therefore, it is difficult to say for sure which is best. We always say that the standard library is where code dies. So for code that has any kind of development potential, the standard library is probably not the best place. Essentially, this adage does n't mean that we do n't want to maintain some of the standard library, but rather that it's due to the nature of being distributed with Python. This means that Python's evolution is very slow because it is locked into its release cycle. So if I want to add a new Python asyncio function or something like that, I have to wait a year or two for it to be released. It would be much more convenient for me to publish directly to PyPI. So, the standard library is really nice. It's really great that we have this. But adding all the necessary things to the standard library is not the only solution. Generally, only specific and universally necessary topics should be kept in the standard library. That's the goal, right ? Thank you. Let's move on to the next question. Speaking of performance: can Python do more optimizations? Like function inlining before generating byte code, maybe through an opt-in feature like O2? Kenjun, will you say 'no', or shall I? The short answer is no. Yes, I'm interested in hearing the reason for your ' no'. So, keep going. Of course. It's much more dynamic at that stage. Byte code compilers can only analyze based on syntax, nothing else. We can do some things, like if there's a 'raise' somewhere, we can say that it probably won't happen often, because people don't usually do that. So we can slightly improve performance by refactoring the byte code a bit and moving that code out of the main stream , but it's hard to do much more than that in byte code. IT (JIT) has a lot of information. It can see live type , know how often each is being used, etc. So yes, we have left all this to either the Specializing Adaptive Interpreter or the JIT. Okay, thank you. Any questions from the audience? Of course. There seems to be a lot of effort being put into getting new contributors to C Python. Last year there was a great discussion about how to contribute without being a compiler engineer. I am a compiler engineer myself, yet I find it quite difficult to contribute to C Python. If there is a lack of maintainers—I haven't tried yet— what other way is there to become a C Python contributor? Come and talk to me after this discussion. Of course I will. Yes. But ...yes. Does anyone else want to answer this? I'm repeating what I said before. Just keep your first contribution. Correct any typos or minor mistakes in one line , then maintain that consistency. Okay. Maybe, my question is, is adding new contributors a big problem for you, and do you know of any way to overcome this obstacle ? Of course, you have to start with some work. You can't just come and say, " Here I am." I am interested in working, please employ me. It does n't usually work like this. The way it usually works is that you start making small contributions. You start helping out sometimes and then people find you , cooperation increases and you better understand what to do and what not to do. I think that while the " I'm here, use me " mentality works in a company's hiring process , it doesn't work very well in the open source community. Okay, thank you. Quite. Let's move on to the next question. That's a pretty interesting question. Is there any part of C-Python that you're afraid to touch? I usually stay away from compilers. Yes, it's better to stay away from the compiler. I mean, it's okay , but it's hard to wrap my head around the whole thing. And I rarely touch on it, remembering everything or finding out where everything is is quite time-consuming. Of course, this is not the case for everyone. You know, to Pablo it's like his beloved child. However, in my case, yes, the compiler. Anyone else? C- What part of Python are you afraid to touch ? Parser. Because if I touch the purse, it means millions of people will be angry with me. Like, are you talking about people or just... yeah, like syntax changes, you know. So, usually if you do something like that, it's very controversial. So, I'm not going to touch that. Test suite. Oh, really? Okay, okay. I mean , the argument could be a parser. There are so many private classes that everyone imports, it's impossible to change any implementation details without breaking anyone's code. This is quite scary. I'm surprised no one is talking about makefiles. Or about the build system as a whole. Okay, we're almost out of time. I wonder if anyone from the audience has any questions? Not yet. Well, another interesting question. Statement as expression. Yes or no? Yes. No. Does anyone else have any opinions? I need to think about it a bit. I've always liked the idea , but I'm not sure if it's possible to incorporate it into Python syntax. There are many complex situations or corner cases. I mean, that's how Rust works, and I love Rust, but it's a completely different language. I think it's too late to add this to Python , but Python should remain as it is. Yes, that would be great. Yes. Didn't you say a little while ago that you don't like converting assignment statements to expressions? That's different. That's something special. Yes, I am for continuity. It has worked for years and I wait. We are approaching the end. Maybe one last small question. Um, how do you debug C Python? Do you use a debugger? Do you use print statements? Both? What is your way to debug C Python? I have never used a debugger. I only use print. I also come from medieval times. I also use print. Sometimes when a situation does n't make sense at all, I resort to the debugger. But usually, after a while you become so experienced that one or two print statements make the point clear. So the extra hassle of running the debugger or setting break points seems too much. Um, C Python often crashes with the changes I make. So a debugger is definitely needed, because then it's too late for the print statement. And once we understand where it's crashing, we can add a print statement. I use GDB, but when it comes to threads , and I have to work with it a lot , it can be really painful . There are some tools that help debug thread related issues, but um, it's a pain in the ass in most cases. What um, I used to use printf and my IDE debugger a lot, but recently my IDE debugger has been broken, I do n't know why. So recently I tried leaving it directly to AI. Yes sorry, that's basically it, but yes mostly printf. Another thing I use a lot in Python is debugging through the REPL. Just hold and test each statement. This is great. Claude. Right. We have two minutes. One last question for each of you, as a closing statement. What is one practical thing that everyone in this room can do to help the Python project ? Um, ask your company to fund the PSF so that another developer in residence or someone like that can be hired. Agreed. Yes, that's what I wanted to say too. Then, you have to think of something else. You can't add plus one anymore. I would say, if people feel comfortable, they can be more involved in contributing. There are many different ways to contribute, and many of them do n't even require writing code. It can be very simple , like supporting someone to contribute , because sometimes someone needs a little support to have the strength to contribute. People can do many small things to contribute , like code reviews, which someone mentioned earlier. I mean, it would be a huge help. Bug triage or similar tasks are great ways to help, because everyone here is a volunteer. Therefore, not everyone has enough time to do many things. The more hands you raise, the better. Yes. Thank you. I would say that instead of thinking about what you can contribute to Python— which is a great thing to do, and thank you for that —you should instead think about: What do you enjoy doing for Python ? For example, if you enjoy doing things like organizing conferences, then do that. At the end of the day, your own happiness is what matters most. Yes. Yes. I agree too. Yes. What I was actually going to say is that we are all contributors. Many of us are professionals, but you are not. So contribute to the work you enjoy doing and leave the boring tasks to us. I would say, don't be afraid to join discuss.python.org. I think there's a tendency in these types of forums where people with very strong opinions tend to post their opinions repeatedly, even though they're usually in the minority. And there may be a silent majority who are in favor of change, but their views are not reflected in the discussion. So, do n't be afraid to get involved even if you don't have a strong opinion on something, and especially if you feel positive about a proposal, do n't hesitate to participate. Yes. If I could add anything to this , there is a dev guide. So if you're interested in contributing , as a first step, check out devguide.python.org, which has a detailed guide to the entire contribution process, including how to compile or checkout Python. If you are interested in contributing to Cython, I think this is a great starting point, and if you have any suggestions , the entire code is on GitHub , so you can also improve the dev guide. And I think our time is almost up. Thank you very much for today and thank you all for the questions. I'm sorry that I couldn't read all the questions in this code, but we tried our best. Our time is limited. Thank you very much. Thank you all for participating. Thank you.