Hi,
Coordination on large Python changes
I’m contributing to Python for 15 years mostly by writing code and reviewing changes. I would like to contribute differently by being part of the Steering Council: work at the organization level to better coordinate and help large Python changes: make sure that all stakeholders are involved and can provide feedback (before, during and after the change).
Python is mature and have a large user base. Changes cannot be done the same way that there were done 5 or 10 years ago. More coordination is needed and a migration path should be well designed. For example, we should always have a contingency plan (since things never goes exactly as planned). I can use the experience that I acquired by driving some previous changes.
On one side, I would like to make sure that it is still possible for Python to evolve to be adapted to new use cases and new platforms. On the other side, the Python community needs to design more guidelines and guidance on how to conduct these changes.
PEP 13 says that the Steering Council should “seek consensus among contributors and the core team before acting in a formal capacity”. I would like the Python community strengths: working groups (documentation, typing, C API, …), diversity and consensus. The council should only be involved if a situation is blocked once everybody had an opportunity to speak up: when there is a clear disagreement and a decision should be taken.
In 2020, I was already part of the Steering Council, but I couldn’t be as available as I wanted because of personal issues.
Mentoring, diversity and reviews
While the Python development is highly technical, Python is also a diverse community. I would like to make sure that Python remains welcoming to everybody and that contributing is as smooth as possible.
Mentoring is a nice way to create a safe place to discuss about anything, build a trust relationship, and for me also to discover workflow issues: things that I learnt to work around, and things which are obvious to me, whereas it’s not for newcomers. Mentoring should be promoted and be part of our culture.
We should value even more reviews and rely on contributions reviews, since core developers have limited availability. I’m trying to review changes of developers reviewing my own changes. Exchanging reviews is a practical way to promote reviews.
Towards a stable C API
Last years, I identified that the C API is a bottleneck for the Python future, and I’m trying to address this problem: identify API issues, propose new APIs (without known issues), and design a migration path towards these better APIs. The migration created a friction last years and should be adjusted based on the feedback and experience that we acquired on these changes
My agenda is to move slowly towards a more stable C API in the long term. While the limited C API (and the stable ABI) is an appealing target, there are still missing features, and a migration path still has to be designed to move most projects to it.
On the other side, Cython prefers to trade compatibility for best performance, but Python still lacks APIs for that. Cython has to copy/paste C code, or use the internal C API, which has a maintenance cost (need update at each Python release). We should provide a documented and tested API designed for performance, with weaker backward compatibility than the regular API (maybe using the PyUnstable API, PEP 689).
I’m now part of the newly created C API Working Group. Having also a seat on the Steering Council should help to have better coordination and make sure that Python remain consistent overall.
My C API talk at the core the sprint (Brno, October 2023) describes my agenda and the work already done. I wrote the pythoncapi-compat project to use new API on old Python versions.
About me
Affiliation: I’m working for Red Hat (which is part of IBM).