I am self-nominating myself for the last time consecutively for the steering council; after 2023 I at least want to interrupt my self-nomination run to make sure you all aren’t voting for me just out of habit.
I am currently the only SC member who has been on the council continuously since its founding (which is weird for me considering I was the youngest core developer when I got my commit privileges back in 2003), so if I am lucky enough to be elected again this would make it my 5th year on the council.
As I have said in previous years, if you’ve been happy with the SC then feel free to vote for me, but if you have been unhappy with it then please don’t vote for me.
While being on the SC isn’t about power (and honestly probably hurts you more than anything as you lose your own vote for any PEP you propose ), to give you an idea of where my head is and what I want to work on in 2023 I am hoping to develop:
- Guidelines on the stdlib (i.e. what do we want it to be, guidelines on what should go in, how to manage it, etc.).
WebAssembly (and specifically WASI) to a tier 2 platform.
(I’m also still working towards lock/pinned dependencies files on the packaging side and doing stuff with the Python Launcher for Unix, but that’s outside of Python core).
And I’m purposefully keeping this short so you all have less to read.
I sure hope the SC is going to keep encouraging and factoring in these elements, whether “core” or not. They’re far more impactful on our users’ experiences than basically anything we do in the language or runtime right now, and don’t deserve to be left out of any grand visions or designs.
I think that leads to a wider question of widening the scope of python-dev then. Since the SC looks after Python core and e.g. packaging is delegated to the PyPA group, one could argue it falls outside our purview. But if you’re suggesting/asking the SC to take a larger, holistic view of everything Python, then that feels like an expansion of responsibilities and one that the Python core team will have to agree to. Otherwise we are now starting to take away from the PyPA who don’t even get to vote for the SC.
You’re right. I did what most of us did and read into PEP 13 what I wanted to see, which was taking responsibility for the vision for Python in its entirety (and hence my strong desire to allow external candidates). That’s not in there, so it’s very much just covering python-dev. Too bad.
I would have argued that if the SC has the authority to delegate to PyPA, that by definition it must fall within the purview.
Right now it’s more like a non-compete agreement
Strictly speaking, we delegate the ability to accept packaging-related PEPs to the PyPA following their own practices outlined in PEP 609 – Python Packaging Authority (PyPA) Governance | peps.python.org . So if they choose to operate without our delegation by simply not using PEPs they could totally do that.
Otherwise the only other thing I can think of that python-dev controls package-wise, now that distutils is out the door, is
Yep, or “please deal with this because we don’t want to” agreement depending your viewpoint of packaging.
Keeping such a community governance split from happening was one of my key goals in volunteering for the inaugural SC - packaging and the interpreter’s import system and interface stability guarantees are too closely entwined for complete independence to be feasible, and securing Guido’s original standing BDFL delegation to specific PyPA contibutors/supporters genuinely helped resolve some of the political conflicts in the packaging community (as well as providing clarity for the wider Python community), so I wanted to see that continue into the SC era.
The enfranchisement side of the question has definitely been an ongoing concern though, mitigated by the fact that there are several folks that are both PyPA developers and CPython core devs, as well as by the mechanics of the standing delegation process. SC interest in improving the management of that broader scope of responsibility would definitely be appreciated.