I am nominating myself for re-election to the Python Steering Council, 2026 Term. I have been a core Python developer since 1994, and have served on the SC during the 2019, 2020, 2021, 2024, and 2025 terms. I work for NVIDIA.
Gratitude
Looking back on the 2025 term, I first want to thank my fellow Council members: @pablogsal, @Emily, @gpshead, and @corona10. It has been a joy working with all of them, both because of the outstanding people they are, and also because of their deep commitment to the Python community and language. Each brings a unique and diverse perspective to the issues the Council faces, from the highly technical to the compassionately personal. It’s been an honor serving with them in service to you, the Python users, developers, core team, and community. This term has been a model for how well a council can function when its members respect and appreciate each other.
Reflections
There’s something to be said about bringing new blood into the SC. Fresh perspectives are always welcome, and as Python itself grows, new leaders are also rising from within our community. Some have argued that “old timers” like me should step aside and let those new leaders bring their vision for Python to the SC. While cogent, I think balancing that with continuity and experience is also important. Ultimately, as I was trying to decide whether to run again or retire, I asked myself two questions: am I bringing positive value to Python by serving, and am I having fun?
I can easily answer “yes” to the latter, especially during a relatively drama-free year where we considered many excellent proposals, making Python 3.14 one of the best releases ever. The SC’s role is the tip of a very large iceberg, and each and every one of you deserves the bulk of the kudos for the hard work of actually maintaining and evolving Python. Way back when, Python appealed to me because it made programming fun where so many other languages make our endeavors tedious, and all these years later, Python is still fun. If being on the SC wasn’t fun, I wouldn’t run again.
Have I brought enough positive value to Python to deserve your trust for another term? Is it time to re-retire Barry from the Council so that new leaders can take the reins? I believe I have. Ultimately, those are questions for you to answer!
2026 SC Goals
A recurring theme this year has been the difficulty of authoring and shepherding PEPs. Some DPO threads get so long, keeping up with them can be a full-time, stressful job. For example, the PEP 810 (lazy imports) thread was 466 posts, one of the longest in recent memory.
Some PEPs get split into multiple threads, perhaps because of competing proposals, or “reboots” for significant updates, or for detours into other related off-shoots. Long threads can burn PEP authors (and others!) out and sometimes good ideas just get abandoned. Thread participants can feel like their objections and opinions are dismissed out of hand. They feel they aren’t being heard or their arguments aren’t given the weight they deserve. Authors can feel like they’re just rehashing decisions that they’ve already settled on. SC members feel an obligation to review the entire thread when making a decision, which really isn’t feasible, and can delay the process for weeks. Even worse is the second-guessing that can happen once a decision is made, which can erode confidence in the process and demoralize everyone involved. I can empathize with the frustrations that led to Guido’s stepping down as BDFL after the PEP 572 (walrus operator) decision.
The irony in all this is that those of us who created PEPs back in 2000 were motivated to provide a lightweight process for Guido to make informed decisions about community-led proposals without getting overwhelmed. I suppose it’s a testament to the PEP system that it’s served us pretty well overall for 25 years. It’s also not surprising that we might need to re-evaluate what still serves us, and what no longer does, given all the changes in communication patterns and the growth of Python over the years.
There have been jokes that the PEP process is a gauntlet, not to be undertaken lightly or by those who don’t have strong armor, but that can’t be acceptable. We need find a better balance so that no one ever dreads championing a PEP.
The SC has had discussions recently with folks who care about improving the PEP process, and there are some good ideas worth pursuing further. Making the process of evolving the language pleasant again will be a priority for me this year.
I also think the SC needs to do better at communicating, especially when it comes to sharing agendas and meeting recaps. This year, we’ve been a little better at posting our meeting summaries to the #steering-council-comms channel on Discord in a relatively timely manner, but we do sometimes get behind. By being more transparent about upcoming and past deliberations, the SC can help PEP authors and the rest of the community feel more connected to the process.
Final Thoughts
I continue to be excited about where Python is going, and I sincerely believe that Python is as useful, relevant, and fun to use as it’s ever been. The CPython implementation is well along the path of removing the GIL, which is probably the most significant milestone in its life, certainly since the Python 2 to 3 migration.
We have an amazing developer community and core team who continue to improve Python. We are growing our next generation of leaders, who are shaping Python into the language for their future and in their vision. Like any diverse group of people, we have our challenges socially, and as the technology landscape continues to evolve, Python needs to adapt while staying true to its core principles. Python is used everywhere which is is both a blessing and a curse, adding to the complexity of every proposed change. I know that when we come together in a positive, respectful way, we can succeed.
Thank you for your support and trust, and if you think I can still help contribute to Python’s future by serving on the SC for another term, I thank you for your vote.