Steering Council nomination: Victor Stinner (2020 term)


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 :slight_smile:

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 (more active than the bug tracker bot :slight_smile: ).

I am paid full time by Red Hat to maintain Python upstream ( 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 :slight_smile: ). 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.


Regularly, I fix various issues related to locales, encoding and Unicode. Examples:

Adding a new UTF-8 Mode (PEP 540) to Python 3.7 was one of my latest and greatest achievements :slight_smile:

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



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.


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 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 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 :wink: ).

In parallel, I also created 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 : 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:

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 :slight_smile:


I am happy to see this nomination. I think with all honesty in terms of long term sustainability of Cpython, Victor has worked hard in mentorship, encouraging and recognising new contributors on the project. From giving new contributors who deserve more roles like triaging, nominating them for promotion. This has encouraged many new contributors to feel like their work on Cpython is valued.

Not that other core deveopers are not. I would personally look forward to some of his more contributons in this area and others while on the steering council.