Alright, let me ignore impostor’s syndrome and let y’all decide if I should help make decisions.
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
- PEP 652 Maintaining the Stable ABI
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 394 The “python” Command on Unix-Like Systems
- PEP 627 Recording installed projects (revision of a packaging spec)
- 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.
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.