After thinking about it a lot (and sorry for the dramatic last-minute nomination 
) I’m nominating myself again for the Steering Council 2025 term.
I do really apologize for the wall of text but everybody who has interacted with me knows that I talk a lot so probably this won’t come as a surprise
This past year has brought both significant achievements and complicated challenges that have made me reflect quite a lot in the SC role in the evolution of the Python language and community. While I think we’ve made important management and technical achievements (which were very much not easy - PEP 703 was a particularly tricky beast), I must acknowledge that we’ve fallen short in crucial areas, particularly in how we communicate with and maintain the trust of the community we serve. Many of you have reached out to express your disappointment in how the SC has handled communication around important decisions and changes that affect the community and how the CoC processes were handled. Although this is an important matter (covered later in the text), I do want to address separately the problem with communication as some have told me directly that trust has been damaged. I want you to know that I take this feedback extremely seriously - it has been a wake-up call that we need to do better.
Despite these challenges, I remain proud of what we have achieved together in the 2024 term. We’ve navigated some of the most significant technical decisions in Python’s recent history, from the acceptance and planning of PEP 703’s free-threading proposal happening at the same time as major technical changes like the JIT compiler at the same time we try to solve dynamic type annotations. We’ve expanded our Developer-in-Residence program to include additional developers and continue finding sponsors for them (I am proud to say that my employer has renovated the sponsorship for another year), securing funding and support for these crucial roles. The working groups we’ve established have proven incredibly valuable - particularly the Typing WG’s recommendations on typing-related PEPs and the Documentation WG’s efforts to investigate and address the evolution of Python’s documentation. We have also started to investigate ways to improve the mentorship experience (first baby steps but we have some ideas for a working group) to better support our growing contributor base, though there’s certainly more work to be done here.
I want to especially thank my current Steering Council colleagues in this term: @barry, @emily, @gpshead and @thomas. I am very lucky to have spent a considerable amount of time this year with them and I cannot imagine navigating this challenging year without their empathy, and dedication. Although we sometimes have very passionate disagreements I have always enjoyed the technical discussions and having your support when dealing with all these challenges and projects together 
Steering Council Agenda
Rebuilding Trust Through Better Communication
The most critical feedback I’ve received this year is about communication and transparency. Many community members feel disconnected from SC decisions and processes. If re-elected, I commit to working on concrete improvements in how we communicate, including finding ways to have clearer channels for feedback (especially criticism), creating more transparent decision-making processes, and finding ways to share our deliberations earlier and more openly. We need mechanisms that allow the community to tell us when we’re getting things wrong, and we need to demonstrate that we’re listening and responding to that feedback.
Code of Conduct Enforcement
This year has brought important discussions about the role of the SC in Code of Conduct enforcement. I think it’s not a surprise that the emphasis and the skillset of the SC is to help advance the Python programming language and help the core developer community advance and solve problems (technical or not). I do not think a group of 5 people are the best group to make the ultimate decision for CoC incidents for core developers (remember that the CoC working group is the group that does the analysis and the recommendation that then is sent to the SC). The reasons are:
- I do not think core developers should be different from anyone else in the community regarding these events and how they are handled. When the CoC working group has a ruling it directs it to the SC (instead of the board as like everyone else) only if the person is a core developer. I think the process should be the same for everyone whatever the process is.
- We are already over the limit of what we can do. We had to double our meeting time to cope with all our responsibilities which now include managing 3 developers in residence, keeping track of the work, securing future funding, reviewing peps, addressing petitions and feedback via email, help creating working groups, and much more.
- We are more biased than other groups because all these events are about core developers from the community we represent and all of this is extremely emotionally and mentally taxing. Separating our personal opinions to what it’s the best course of action for everyone like we do when we review PEPs (we try to represent what its best for everyone, not what we think) is ridiculously hard.
Many of you have reached out expressing that you believe the SC should maintain its role in these matters, citing that the SC has deep context and understanding of the core dev community in particular. Others have raised valid concerns about this arrangement. Although my position in general is that the SC is not the best body to deal with this and I support changing PEP 13 to that regard I take all perspectives seriously and believe that whatever path we choose, we need clearer processes and better support systems for all involved parties.
Improving User Experience
A key focus of my work has been making Python more accessible and user-friendly. Having started projects like the better error messages, the new REPL and improvements to debugging and profiling tools I understand how impactfull these user-facing improvements are. Many community members have expressed concerns that with the increasing focus on performance, we risk losing sight of a very important part of what makes Python special for a lot of people - its accessibility to newcomers, students, and individual developers. These concerns resonate strongly with me. The excitement I’ve seen from the community about recent improvements in error messages and debugging experience reminds us that while performance is crucial, the usability of the interpreter and the ability of a newcomer to understand what went wrong with their code are equally important. I want to continue emphasizing user experience in SC decisions, ensuring that Python remains approachable while becoming more powerful. Every technical decision we make should consider its impact not just on our professional users, but on educators, students, hobbyists, and individual developers who make up the heart of our community.
Empowering Working Groups
I think that the success of working groups like typing, docs, and C-API has proven that this is a very successful model to follow. Over the past term, we’ve seen how these groups can greatly help the SC and reduce the load while providing focused guidance and recommendations. One good example of this is how the Typing WG has helped guide typing-related PEPs and how the Documentation WG has driven improvements in Python’s documentation. But we can do more. I want to continue empowering these groups while encouraging the formation of new ones where needed (including a mentorship working group). By better coordinating the Steering Council with these working groups, we can not only delegate responsibilities more effectively but also ensure that we can leverage the working group to do a lot of the fieldwork that the SC requires to understand the landscape in some of the specific decisions.
Support performance and free threading Python
Python is at an exciting crossroads with multiple big initiatives that somehow are happening at the same time like free threading, the JIT and the general work on performance. As these improvements receive significant contributions from different companies and user groups, each with their own priorities and requirements, it’s crucial that we find ways to balance these needs and to ensure that we are working towards a shared vision for the community. This is particularly special since some of these work areas are (currently at least) partially incompatible with others so alignment is particularly important. We must ensure that performance improvements serve the broader Python community while maintaining the language’s accessibility and ease of use. This means carefully evaluating how different initiatives can work together.
Supporting Mentorship and Community Growth
Mentoring is more crucial than ever for Python’s future. As the language grows more complex and maintenance demands increase, we need to ensure we’re not just maintaining our contributor base but expanding it with diverse voices and perspectives. Apart from working with the people I mentored in CPython, this past year, collaborating with Łukasz on the core.py podcast has been particularly rewarding. We started the podcast as one of our key objectives has been trying to make the voices and work of both core developers and contributors whose crucial contributions often go unnoticed louder. We have already seen how conversations with both seasoned and newer core developers have inspired people who would have never given core development a go to contribute to Python. I believe there is a lot of value in this and I would like to continue finding ways to keep improving.
Building on our current mentorship workshops, I want to work towards creating more structured support systems for both mentors and mentees, addressing gaps in our current processes, and finding new ways to attract and encourage contributors from all backgrounds, especially from the groups that find it currently more inaccessible.
Work as a core developer
- 3rd most active core developer since my promotion.
- Core developer since 2018-06-06.
- Release manager for Python 3.10 and Python 3.11.
- Focused on improving the user experience with the better error messages project to improve the error messages and general user experience in CPython. Examples of this work:
- My work is centred on the parser, the compiler, the garbage collector and the VM in general but I more or less work all over the place, maintaining also some of the CI bots (buildbot integration) and workflow.
- Added tracebacks in the REPL (really this was not there before).
- Spearheaded the implementation of Python’s new default REPL, bringing features like multiline editing, direct support for REPL commands, colored output, and improved history management.
- Enhanced Python’s debugging experience with new colour support for tracebacks in terminal output.
- Maintained and improved various debugging and profiling tools used by the Python community.
- Developed support for the perf profiler, working without frame pointers and debugging support in collaboration with the Linux kernel and perf developers.
- Continued the better error messages project, making Python more approachable for users at all levels.
- Maintained and improved various debugging and profiling tools used by the Python community.
- Several major improvements to the devguide, including the new Design of CPython’s Garbage Collector which has been very well received by many core devs and contributors and the guide to the new peg parser.
- Python 3.10 better error messages
- PEP 657
- I created and maintain one of the most popular memory profiles for Python: memray.
- I maintain several Python debuggers and stack analyser tools such as pystack.
- Made several events to demystify core development and the release process and get closer to user such as the 3.10 release stream party and the 3.11 release stream party.
- I work considerably on performance and I collaborate with the Faster CPython project. Some of the performance improvements I have worked recently include the work on Python call inlining, adding support for the perf profiler, GC improvements and many more.
- Maintenance and improvements of the Python speed server: speed.python.org. This involves running automatic benchmarks, cross-validation and monitoring the different benchmarks in a stable and reproducible manner and open issues in the bug tracker if performance regressions have been detected.
- Add checks for ABI stability
- Maintenance of the buildbot server and the CPython CI:
- Watch and monitor daily the buildbot server to spot failures, report them to the bug tracker and fix them (almost all of them if possible).
- PSF blog post covering my talk about the buildbot work at the Language summit.
- GitHub-buildbot server bots integration improvement to the GH workflow
- Many improvements to the buildbot server as the new release dashboard.
- Added a new
test-with-buildbotslabel to test a particular PR with the buildbot fleet. This has reduced considerably the number of reference leaks reported since it was added. - Organized and hosted the core developer sprint of 2019 in London.
- Mentored / promoted several new core developers:
- Paul Ganssle
- Lysandros Nikolaou
- Brandt Bucher
- Batuhan Taşkaya
- Ammar Askar
- Ken Jin
- Michael Droettboom
- Organization committee of several conferences such as:
- PyCon Spain
- PyLondinium
- Authored & Co-authored PEPs:
- PEP-delegate for:
- Plenty of new additions to the standard library (I will not list them here to not make this post too big, but you can check them in the “What’s new document” of the different releases.
For more information you can check some of my endorsements for from my past nomination.
Online Presence
Conferences
Speaker at different conferences and meetups including PyconSpain, PyLondinium, EuroPython, PyConUs… I am intentionally keeping this short to not make a wall of text, but if someone is interested I can provide links to all the talks + publications.
Affiliations
I work at Bloomberg on the Python infrastructure team in London.
My time and availability
Although I dedicate a considerable amount of my free time my employer (Bloomberg) allows me to spend up to 50% of my time on Python.
If anyone requires more information or clarifications regarding these points or has other questions, I will be pleased to answer them or provide more extensive information.
If you have arrived here, thanks a lot for reading the full thing 