Hi,
I’m nominating myself for the Steering Council (2020 term). It’s hard for me to announce what I will do at part of the Steering Council, it’s easier for me to elaborate on what I’m currently doing for Python, and what I did over last years. I’m working on many aspects of Python in parallel. This message is mostly about the work I did during the last two years on Python 3.7, 3.8 and the future Python 3.9. Sorry, it’s longer than what I expected 
About myself
I have been a Python core developer since 2010 and one of the most active contributors in term of commits. I also read once that I’m one of the most active on bugs.python.org (more active than the bug tracker bot ).
I am paid full time by Red Hat to maintain Python upstream (python.org) and downstream (Red Hat Entreprise Linux: RHEL, and Fedora).
I got 11 PEPs accepted and 10 rejected. My accepted PEPs will give you an idea of my areas of interest:
- Python Initialization Configuration (PEP 587): better C API to embed Python into an application,
- time.time_ns() (PEP PEP 564),
- Python Documentation Translations (PEP 545, co-written with Julien Palard and Naoki IANADA),
- UTF-8 Mode (PEP 540),
- Make os.urandom() blocking on Linux (PEP 524),
- Retry system calls failing with EINTR (PEP 475, co-written with Charles-François Natali)
- tracemalloc module (PEP 454),
- Make newly created file descriptors non-inheritable (PEP 446),
- time.monotonic(), time.perf_counter() and time.process_time() (PEP 418)
- etc.
I’m trying to track some of my contributions to Python in the page: My contributions to Python.
Promote active contributors, Diversity and Community
In the last two years, I promoted 6 core developers (Joannah Nanjekye, Paul Ganssle, Stéphane Wirtel, Cheryl Sabella, Pablo Galindo Salgado, Julien Palard). I mentored most of them. I also gave the bug triage permission to 8 contributors.
I started different discussions and gave conferences to try to get more core developers onboard. My latest talk at Pycon US, May 2019: How to engage Python contributors in the long term? (“Tech is easy, people are hard.”).
I wrote a tutorial (how to contribute to Python). I wrote a formal process for promotion (it may remain a draft, it’s too formal ). I mentored around 15 developers since 2017: some have been promoted as core developers, some got the bug triage permissions, others decided to move to a different project.
I actively worked on increasing the diversity of core developers. I chose to mentor more women than men.
System programming
I like to review changes that expose new system function in Python (os, shutil, signal and threading modules for example).
I’m working on enhancing Python portability.
I fixed many complex issues about signals, threads and race conditions related to that. “Retry system calls failing with EINTR” (PEP 475, co-written with Charles-François Natali) and “Make newly created file descriptors non-inheritable” (PEP 446) are deep Python changes to reduce race conditions.
Unicode
Regularly, I fix various issues related to locales, encoding and Unicode. Examples:
- Locale Bugfixes in Python 3 (2019)
- Python 3, locales and encodings (2018)
Adding a new UTF-8 Mode (PEP 540) to Python 3.7 was one of my latest and greatest achievements
By the way, I wrote a serie of 6 articles telling the history and rationale of the Python 3 Unicode model for the operating system, starting with Python 3.0 listdir() Bug on Undecodable Filenames and ending with Python 3.7 UTF-8 Mode.
Python CI: buildbots, Travis CI, Azure Pipelines
Website: https://pythondev.readthedocs.io/ci.html
With Pablo Galindo, I’m part of the The Night’s Watch who is Fixing the CIs in the Darkness for You!
I’m trying to fix every single CI issue to ensure that the CI doesn’t block the Pyhon workflow (it would prevent the merging of any PR!). I’m also trying to fix tests which fail randomly (“flaky tests”).
In practice, it means that I’m reading buildbot-status emails (buildbot worker failures), I create an issue for each failure (but avoid duplicates), and then try to fix it. Usually, we assign the failure to the author of the change which introduced the regression.
Better debugging experience
I modified Python 3.8 to get the same ABI as the release build: Debug build uses the same ABI as release build. It means that a debug build (“python3.8-debug”) can be used without recompiling C extensions: it helps a lot in debugging of C extensions bugs.
I added many assertions (ex: to the gc module). I enhanced Py_FatalError() and similar functions to provide more information in case of a Python crash. I also modified Python 3.8 to dump the Path configuration if importing the filesystem encoding fails, to help users to debug their setup.
One of my motivations for this overall work is to help Red Hat customers to debug their Python issues, especially tricky bugs in C extensions.
Security
I backport security fixes to all supported branches (2.7, 3.5, 3.6, 3.7, 3.8 and master) and keep track of fixes at python-security.readthedocs.io. I also wrote a tool which implements functional tests for known Python vulnerabilities.
I am also part of the Python Security Response Team (PSRT) who handles vulnerabilities in private.
In Python 3.6, I modified os.urandom() to block on Linux until the kernel collects enough entropy (PEP 524), to enhance the security.
Python Performance
I’m working on Python performance to ensure that Python remains competitive.
I wrote pyperf, rewrote pyperformance (official Python test suite), wrote documentation how to run benchmarks, and finally updated https://speed.python.org/ to track Python performance over multiple years.
I’m trying to help Eric Snow to implement his subinterpreters PEP 554 (see my “tstate” thread on python-dev this week 
).
In parallel, I also created pythoncapi.readthedocs.io website to discuss how the C API is preventing us to optimize Python and try to find concrete solutions.
I already pushed many changes into Python 3.8 to enhance the C API (see my article Split Include/ directory in Python 3.8).
I am also trying to help the HPy (or “PyHandle”) project to become a reality: it’s a new C API written from scratch, designed to be efficient on PyPy and CPython, and not leak any implementation detail.
Incompatible Changes and Coordinated Python release
More recently, I started to work on https://github.com/vstinner/pythonci : a experimental CI project to run coverage, Jinja and numpy on the master branch of Python.
I proposed “Python Compatibility Version” (PEP 606) and “Coordinated Python release” (PEP 608) which have been rejected. The PEP 608 has been rejected, but it seems like most people agree that we have to work on such CI to better coordinate Python releases. I’m still working on that at Red Hat.
The main idea is to open a discussion on incompatible changes and how we should deal with them to prevent breaking too many projects at each Python release.
My Python websites
I have different websites about Python development:
- https://pythondev.readthedocs.io/ : Python development
- https://pythoncapi.readthedocs.io/ : Python C API
- https://python-security.readthedocs.io/ : Python security
- https://cpython-core-tutorial.readthedocs.io/ : Tutorial to contribute to Python
- https://faster-cpython.readthedocs.io/ : Python performance, how to optimize CPython
-
http://vstinner.github.io/ : My blog is mostly about Python development
My previous self-nomination for the first Steering Council, January 2019: Steering Council nomination: Victor Stinner
MINOR EDIT: Kyle Stanley fixed many typos in my message