I nominate myself for re-election to the Python Steering Council for the 2025 term for 
3.14.
If you collectively see fit to re-elect me, it’ll be my fourth term. I’ve been a CPython core dev for over two decades. You may know me as @gpshead on relevant platforms. A frequent wearer of bright colors. That dev on a bicycle. Creator of hashlib, maintainer of subprocess (and somehow multiprocessing? eek!), Python security team member. Employer? I work for Anthropic.
My Guiding Philosophy
I want to foster stability and CPython ecosystem compatibility while sustaining continued progress on multi-core performance work. I phrase it that way to include efforts beyond the obvious key work in free-threading from PEP-703. I do not want to see us deciding to add more complications to the lives of those working on such implementation than they already have unless it is for the greater good “needs of the many” stability. My long term desire for Python - several years from now - remains in line with the long horizon “open issues” section of 703: I want free-threading to graduate to being available by default even if not on by default, and for us to collectively have settled on community support and performance criteria needed for it to be elevated to the default. My decision making on what changes we do accept will be keeping that in mind. Other parallel efforts 
such as subinterpreters and efficient sharing of data between isolated interpreters are also important to recognize as practical strategies we should support. These all come down to enabling efficient compute resource utilization with less need to abandon Python. #win
Tangentially: Something I wish we as a project could support better in a top tier manner is enabling observability into running Python application performance. Working on better use of resources without an ability for users to measure the practical impacts is a big miss. I know we’ve got some work in progress on that front, but it is something I wish we could promote as a primary goal of the CPython project with regression tests as release blockers. Not having working observability can mean users are blocked from upgrading to more recent Pythons and getting all our other nice things. Not an easy challenge.
Security & Best Practices. I consider software security of CPython and improving our development practices to be a big part of my stability mantra. Python’s user base is now beyond huge. We have a responsibility to the world to improve our practices. The software security folks that we on the 2023 SC helped the PSF hire continue to be an enormous force for Python good. Thus my support for guiding us towards modern best development practices such as mandatory code reviews by fellow core devs.
SC wish list for 2025
Requirement #1: Work with the PSF to ensure that our new SC election voting method is implemented, test voting rounds done, and appropriate people lined up to run and manage that – well before next year’s election.
Figure out if we can run a grants program for targeted CPython related work and what it would look like.
I don’t have well formed opinions on the outstanding PEPs yet. I’ve long seen many needs for some form of PEP-750 Template Strings in a bunch of different code bases. But decisions on that kind of feature always come down to the community’s input and the technical and human ramifications. I feel like we could throw a dart to decide on whether 3.15 or 3.26 follows 3.14.
Even mentioning “deal with PEPs” is getting into the “keep doing the stuff an SC obviously does” territory. So I’ll toss one more out there: Making sure our Developers In Residences are feeling useful, and strategically have them work on priorities when needed. Most of that gets coordinated through the SC’s existing regular sync ups with Łukasz.
Find more opportunities to delegate decisions.
State of the SC as we wind down 2024
Communication: The SC is finally getting better at this, though I don’t know if it shows yet. Onboarding Velda, our Communications Liaison we hired this summer, to deal with notes and summary drafts has helped us have smoother meetings and make progress on sharing. But that’s only the start and I think we see it ourselves internally more than you do… So the continuing SC’s goal should be ramping up to more frequent and meaningful updates on our deliberations.
Our need to set expectations: This year was, unusually, full of drama from the community (it was not all public). Often misdirected. The underlying theme that became very clear is that a bunch of people have unrealistic expectations of two things:
- What the SC roles and responsibilities are. Please, read up on the SC mandate and powers documented in PEP-13.
- How much volunteer time the SC dedicates to doing what and when, and the consequences to the SC’s overall ability to be responsive to the expectations put upon the SC’s time and attention.
These misunderstandings are not unique to one particular Steering Council. It’s a recurring theme.
Why do misunderstandings of our role cause problems?
Both issues get conflated into one when people look to the SC without understanding our role and think we’ve got responsibilities that we don’t, such as: To directly address everything ourselves. Or are somehow magically on-call staff with a single rapid response mind. Or that we as a body are elected to solve larger systemic tech issues. Or that we are moderators. Or that we should look the other way and ignore behavioral issues that were driving people away from our community. Or that we’re out to get you. None of those is true. Yet the 2024 SC witnessed all of those expectations directed our way from differing sources this past year. 
The SC’s role is to enable you to do good things for Python in the long term by planning appropriately and making the hard decisions that a community cannot reasonably do themselves. Whether it be “simply” (hah!) breaking technical decision ties where there is a lack of consensus, or the sad but critically important job of applying thankfully rare corrective measures against a core dev for the health of our community. No SC ever expects 100% agreement with any decision. But every SC expects you to trust that they are doing what’s best for the greater good of Python and our community and they will do their best to explain why.
The SC role as I see it is high level. We aim to empower others to act where needed. To see that structures are set up such that appropriate things happen for the Python project that we collectively trust. That’s why we’re happy that we can empower others and rely on people in the working groups / councils / etc. focused on specific areas such as typing, the C API, cheese wheel farming, and the PSF organized conduct working group (which a few core devs volunteer for, thank you for your service!) to come back with recommendations that are easier to consider and trust given the existing domain expert input.
Did this past year annoy me? Absolutely. Yet I am volunteering for another round because we’ve still got work to do to improve how we’re running as a project and pave the way for a new generation of core devs to be doing all of this in the future.
So what can the next SC do about it?
I believe most core devs are aligned with these expectations and trust the SCs of the past, present, and future. But the next SC needs to try to make our role and what people can expect more clear. We need to foster an understanding that we must function as a team.
On reply speed: The SC is five independent individuals spread around the world working as volunteers with very limited time. In order to get a response to anything non-trivial or potentially contentious from the SC requires volunteer time and meetings and discussions amongst us. Aside from the trivially easy things we know all of our minds on and can agree upon asynchronously over chat: We will always be a slow body. By definition. There can be no replies from a multi-headed volunteer body presenting a unified face any other way. This also means there are things we’re just not going to be able to spend time on. We’ve been trying to get better at telling people when we won’t be able to respond to things. The next SC should continue improving upon that. But no SC is going to be able to be fast.