Hi, On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum wrote:

I wonder if there's a role for HPy in this context? What if instead of evolving the stable ABI and the limited API, instead we were to focus on first-class support for HPy?

The hope with the HPy project is indeed to provide a C API that is close to the original API to make porting easy and have it perform as close to the existing API as possible. At the same time, HPy is sufficently removed to be a good "C extension API" (as opposed to a stable subset of the CPython implementation API) that does not leak implementation details. To ensure this latter property is why we try to develop everything in parallel for CPython, PyPy, and GraalVM Python. On Wed, 8 Dec 2021 01:47:38 +0100 Victor Stinner wrote:

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.

Indeed, at this point HPy is still evolving very fast. We are still solving issues while migrating NumPy, have begun adding support for HPy to Cython, and will start working on pybind11 soon. I believe by the time we have these users of the existing C API working, HPy should be in a state where it is generally useful and can be deemed stable enough that further development can follow a more stable process.

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.

In the long run the HPy project would like to become a promoted API to write Python C extensions. Tim Felgentreff (on behalf of the HPy team)