On 08. 12. 21 1:47, Victor Stinner wrote:
For me, HPy is the only valid stable API and stable ABI in the long term which is efficient on any Python implementation. Its design is very different than the C API: HPy avoids all C API design mistakes, it doesn't leak any implementation detail.
HPy can already be used today on CPython, even if it's not directly provided by CPython.
Providing HPy as a first-class citizen in CPython, as already done in PyPy, would be great to promote HPy! However, HPy evolves quickly and so needs to be released more frequently than CPython. At least, we could promote it more in the C API documentation, as we already promote Cython.
Promoting the HPy usage doesn't solve any issue listed in PEP 620, 670 and 674 since CPython still has to continue supporting the C API. We will only be fully free to make any change in Python internals without having to care about breaking the C API once the *LAST* C extensions using the C API will disappear... Look at Python 2.7 which is still used in 2021. I bet that C extensions using the C API are not doing to disappear soon.
For me, the question is:
=> Is it ok to no longer be able to make any change in Python internals because of the public C API?
The sub-question is:
=> Is it ok to have a slow deprecation process and wait 5 to 10 years until it will be possible again to evolve the Python internals?
No, they should be evolved when they *need* to be evolved. This PEP calls for breaking things because they *might* need evolving in the future, but doesn't presemt any immediate benefit. In that case, I think it's better document that we don't like some usage, but only do the removals when they're helpful. Especially in cases where there can't be a proper deprecation period.