I’m nominating myself for the Steering Council (2020 term).
For those who don’t know me:
- I’ve been a core developer since 2000, albeit with varying levels of activity.
- I was the first non-Warsaw to author a PEP (other than PEP 1), and the first to author a rejected PEP (an achievement of which I’m still very proud).
- I’ve served on the PSF Board of Directors several times (2001-2004, 2017-2019).
- I worked at XS4ALL until 2006, and arranged for many python.org services to be hosted there.
- I joined Google in 2006, where I work on the (internal) Python team. As people may be aware of, Google is a big user of Python, but we do things a little different than most Python users, internally. I have a lot of experience with the C API, embedding CPython, and weird ways to install or bundle CPython.
- I’m (as
Yhg1s) fairly active on the #python IRC channel on Freenode, which I administer (with a bunch of other people) and which we consider an official PSF channel.
- I’m somewhat active on Twitter (also as
To be sure, I’m not running to oppose anything the Steering Council has done in terms of language direction, governance or the structure around it. I think they’ve all done a great job, and I wouldn’t mind the same council continuing the development of the role and setting the standard for future councils. I want to help out where I can, though, which is why I’m nominating myself for the next council.
Some of the things I know the council has worked on and I want to explicitly support:
- Outreach, diversity, inclusiveness, conduct. The longevity of the language, the CPython implementation and the community as a whole depends on these, and it deserves all the attention we can give it.
- Funding paid work on CPython, and getting corporate support for same. This is a tricky subject, for a variety of reasons, but I think it’s important to fund that which volunteer contributors can’t or don’t want to do, to enable them to work on what they can and like. Python is important enough to many companies that we should be able to build corporate support for such a model, without catering to the companies in technical decisions. Building this up is a slow and careful process, however.
- Encouraging and supporting grand experiments on, and multi-year evolutions of, Python and CPython. I’m thinking of things like Eric Snow’s subinterpreters, Victor Stinner’s and others’ work on the API and ABI, and Larry Hasting’s Gilectomy experiments.
I’m somewhat less concerned about new language features. Although I was and still am in favour of PEP 572 (the walrus operator), I think the pace for new language developments is fine as it is, and we should examine the pros and cons of each proposed feature as they come. I would rather spend more time actively supporting alternative Python implementations, like PyPy, and finding better ways for users to mix and match different implementations.