I’m running for the Steering Council 2022 term.
My Agenda for the Steering Council
- Python maintenance: make sure that it is always possible to merge pull requests; repair every possible CI failure: buildbots, GitHub Action, Azure Pipeline, etc.
- Backward compatibility: Every Python major release comes with its bucket of incompatible changes (Python API, C API, build, etc.). At Red Hat, my team is upgrading Fedora very early to the first alpha versions of the next Python version, and we are facing all packages broken by incompatible changes. Providing early feedback helps to decide if a change should be postponed, or if we should help updating affected projects. We are sending pull requests, or at least reporting issues to upstream. Better collaboration with projects “consuming” Python reduces friction at the Python final release.
- Breaking stuffs!!! It remains important to be able to push large changes to add new Python features (ex: Python 3.10 pattern matching) and to optimize Python (“faster Python”, “no GIL”, subinterpreters?). There is a lot of competition between programming languages. Python will only survive in the long term if it continues to evolve to adapt to new use cases. Obviously, the previous item (Backward compatibility) still matters.
The future Python 3.11 version is going to be challenging in terms of C API backward incompatible compatibility with deep changes in PyFrameObject and PyThreadState structures, and other subtle incompatible changes pulled by the “Faster Python” project: it’s exciting! I’m already working on proposing solutions for that.
My personal interest area
I’m working on the C API for 3-5 years, like PEP 670 - Convert macros to functions in the Python C API. The challenge is always the backward compatibility. One goal is to prepare CPython for optimizations, another is to bend the “default” C API towards the limited C API and the stable ABI (prepare a migration to HPy?).
Contributions to Python
I’m the author of faulthandler and tracemalloc modules, and author or co-author of 11 accepted PEPs (I prefer to not count rejected/deferred PEPs 
):
- PEP 587 3.8 Final Python Initialization Configuration
-
PEP 564 3.7 Final Add new time functions with nanosecond resolution (ex:
time.time_ns()) - PEP 545 — Final Python Documentation Translations – co-written with Juliend Palard and Naoki IANADA
- PEP 540 3.7 Final Add a new UTF-8 mode
- PEP 524 3.6 Final Make os.urandom() blocking on Linux
- PEP 509 3.6 Final Add a private version to dict
- PEP 475 3.5 Final Retry system calls failing with EINTR – co-written with Charles-François Natali
- PEP 454 3.4 Final Add a new tracemalloc module to trace Python memory allocations
- PEP 446 3.4 Final Make newly created file descriptors non-inheritable
- PEP 445 3.4 Final Add new APIs to customize Python memory allocators
- PEP 418 3.3 Final Add monotonic time, performance counter, and process time functions
I like helping contributors to get their work merged into Python: help them to meet developers who know the affected code, guide them in the documentation, review changes, etc. I mentored many developers and promoted 10 developers as core developers (I prefer to not name them here to avoid a conflict of interest 
).
Affiliations
I’m working for IBM/Red Hat: paid to maintain Python upstream (python.org) and downstream (RHEL and Fedora).
Links
- pythondev: My notes about the Python development
- My Twitter account: Mostly about Python
- vstinner’s notes: Random notes, mostly about development