Subject: Re: PEP 674: Disallow using macros as l-value

Hi,

On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum <[e-mail]> 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 <[e-mail]> 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)