I don’t think I never wrote anything about “a universal API”. I wrote about a JIT-friendly universal ABI, which is a very interesting and useful idea introduced by HPy, but which I guess could be implemented through an evolved limited API (with ideas taken from HPy).
My sentence “About a HPy-based solution and a universal ABI, I’m pretty sure that many CPython code devs are not convinced at all.” was a response to @ncoghlan who wrote “So I guess my key point is that the CPython core devs aren’t the people you have to convince”. Anyway, this does not seem very important.
The subject is complicated but I think I start to be not so unclear. But thanks for giving me the opportunity to try to be clearer.
I point out the importance for Python (the language) to have in few years an official JIT-friendly universal ABI (like the HPy universal ABI), which of course CPython would support natively.
For the details of how we should get that (in particular with HPy or with an improved limited API), I think this should be studied with a dedicated working group (gathering in particular CPython, HPy, PyPy, GraalPy, Cython and Numpy people). With a clear and serious plan, I think we will then be able to find funding and support, since this feature would radically change the experiences of Python users, package maintainers and developers of Python interpreters.
It seems to me that the most natural and simple way to get the wanted result (an official JIT-friendly universal ABI natively supported by CPython) would be with a healthy and used HPy. CPython would just need to include a bit of HPy code to be able to natively import HPy universal extensions. So in this case CPython would not need to “support two C APIs”.
However, I don’t know enough to be able to know what would be better, so it really makes sense that a dedicated working group works and gives its conclusions. Anyway, to get funding, we need this step.