On 4/4/2022 11:19 AM, Petr Viktorin wrote:
On 03. 02. 22 1:40, Guido van Rossum wrote: [...]
I understand the CPython is stuck supporting the de-facto standard C API for a long time. But unless we pick a "north star" (as people call it nowadays) of what we want to support in say 5-10 years, the situation will never improve.
My point about "getting one chance to get it right in the next decade" is that we have to pick that north star, so we can tell users which horse to bet on. If the north star we pick is HPy, things will be clear. If it is evolving the C API things will also be clear. But I think we have to pick one, and stick to it so users (i.e., package maintainers/developers) have clarity.
A few months later, here's a draft of a “north star” document. Is this close to what you had in mind?
https://docs.google.com/document/d/1lrvx-ujHOCuiuqH71L1-nBQFHreI8jsXC966AFu9...
"[There is a proposal for an additional “unstable” ring for even deeper integration -- compilers/debuggers. I'm listing it here even though it's not status quo :)] Private API -- internal use only (with specific exceptions)" The Private API is the unstable ring, subject to change each bug-fix release. The proposal is for a semi-stable ring, stable for each version. I agree that 'Semi-public' would be a good name. "(with specific exceptions)" seems like a rough edge. Would most (all?) exceptions go in the Semi-public ring? It seems to me that a big driver for this discussion is the current push to get Python-level results much faster, which most people agree is a good thing. That requires eliminating duplication, doing some thing faster, and somethings not at all. That in turn requires revising internal structures along with code paths. And that in turn requires revision of external code deeply integrated with the core. I think it worth making it clear that the resulting pain is needed for something that benefits most Python users. -- Terry Jan Reedy