Alright, let me ignore impostor’s syndrome and let y’all decide if I should help make decisions.
About me
I’ve been a core developer since 2018, after working with Nick Coghlan on module isolation/stable ABI. I’ve inherited this problem area from him, and I’ve been slowly working on this ever since, mostly in “20% time” at work. Over the years I’ve (co-)authored:
PEP 489 Multi-phase extension module initialization
PEP 573 Module State Access from C Extension Methods
PEP 630 (informational) Isolating Extension Modules
I work in Red Hat’s Python Maintenance team, integrating Python into Fedora and RHEL distros. In this “non-20%” part of my day job, I’ve co-authored these informational PEPs:
PEP 672 Unicode-related Security Considerations for Python
Locally, I’ve helped bootstrap PyLadies CZ in 2013, and every year since then I’ve been teaching Python in free community courses organized by/for Pyladies CZ.
Agenda
Issues I’d like to drive if I’m elected:
Stability. I want Python to be a solid foundation to build upon. Unless there is a real reason to break users’ code, we should not break it. The current guidelines we’ve set for ourselves allow too much trivial breakage, and aren’t even followed in some cases. My opinion, however unpopular, is that we should put stability first. This adds a constraint to each technical puzzle we solve: if I have my way, new features and improvements will be harder for us to add, but easier for users to use.
I’m not saying we can’t have breaking changes, but that we should think long and hard about each one.
Documentation. Although I’m not a documentarian myself, I would like to support a coordinated effort to improve Python’s documentation. I remember the docs.python.org as a shining example of how docs should be done, but it has gone a bit stale since.
My positions on other issues:
Faster Python & GIL removal: It’s no secret that Python can be sped up dramatically, nor (thanks to Sam Gross) that the GIL can be removed. The challenge for CPython is much harder than that: it’s to make the change with as little disruption as possible for users – both their Python code and extensions; in popular open-source projects, personal scripts, and proprietary legacy code.
Subinterpreters & C module isolation: I intend to support this (and my own area of work is a subset of these efforts). Changes should be made more deliberately (and thus slowly) than some of the ones made for 3.10.
Limited C-API is, in my opinion, the future of Python’s C API. Users should be encouraged to use it – by removing limitations, adding speedups, keeping stability, making it easier to use for alternate interpreters and languages.
Mentoring, mediation, CoC: I am neurodivergent and struggle to understand people emotionally, so in these areas, I can’t do much more than nod to people whose arguments make sense. I fully support what the current SC has done in these areas.
Type checking should remain strictly optional, but I would vote for adding it to the stdlib – slowly and gradually, only for the obvious cases. I think that there are parts of the documentation where structured typing information could make things clearer, and in those cases help() output should be improved as well.
GitHub issues migration: While I’ve only been watching this change from the sidelines, I support it, and if I’m elected I’ll research how the SC can push it forward.
Developer in residence: This is a great effort. The SC should work with Łukasz, but also make sure the position scales for more people – possibly ones not as awesome as Łukasz.
While I agree that we need stability, where do you draw the line between avoiding breakage vs possible stagnation and/or allowing users to shoot themselves in the foot with half-broken deprecated features? I recall this recently coming up on python-dev that some think we should maybe leave deprecated features around near-indefinitely to avoid any breakage, so I am curious as to the details of your view on this. Specific examples would maybe help, but otherwise just abstract/theoretical examples are fine.
There’s a lot of ways users can shoot themselves in the foot. We aren’t likely to eliminate them.
Are there users that have used the deprecated features without shooting themselves in their feet – understanding the limitations, reading warnings in the docs, using the features for simple cases only, coming up with well-tested workarounds, etc.? If so, can we find a way to keep the code working, while also providing a path for them to move off deprecated API on they need eg. extra features? And encourage users to not use the old API in new code? If we can, we should.
Throwing old stuff out is easier for us, but adds work for all users that are forced to adapt.
The thread is here: Mailman 3 Do we need to remove everything that's deprecated? - Python-Dev - python.org
Keep in mind that ideas there are not suggestions – some ideas are too extreme to actually implement, but worth thinking about why exactly we don’t want to implement them. I’m not satisfied with generic reasons for breaking stuff, like “CPython must evolve”.
“we should think long and hard about each removal” sums my position up nicely. Every case is different, but overall It’s currently too easy for us to break stuff.
Back to the election: looking at the candidates, if I do get elected you can simply expect me to hold the most extreme opinion on stability :)
I for one like your aspects on stability and want to see more of this on the SC. I agree 3.10 may have had some rushed changes. I am looking forward to more cautious decisions, not the absence of change completely. I think you embody this balanced temperature IMHO.
I cant say that I 100% agree with the degree of non-breakage, but I do understand the perspective better after @encukou’s above explanation. It is good to have at least 1-2 people in favor of strong stability though
I can agree with this, well explained. I think CPython does have to change over time to not stagnate, but it should always be done with very careful consideration. Breaking things causes major disruption to users, so it should be done only when necessary rather than “just because” there’s a marginally more convenient way. Cost-benefit analysis is important, and maybe we have been too eager to break things.
For what it’s worth, as a Python downstream distributor (Fedora) I’d love to have a person on Steering Council who cares about language stability. I see far too many free software Python projects that need to be updated because of changes in Python that could have been easily avoided.
Disclaimer: Petr is my teammate at Red Hat, but I would endorse any other candidate who makes stability their concern.
From my perspective, as a person who mostly works with Python < 3.8, I can say that I’m all on board for stability as a guiding principle.
New features are important, no doubt about it, but not at expense of breaking existing infrastructure. Unless completely necessary, but that goes without saying.
I would also love to see expansion and improvement of the documentation. It is still very good, but there are signs of stagnation.
PS: I work at Red Hat, although not within the same team as Peter.
