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? Obviously, my answer is that we must change the C API as soon as possible to allow again changing Python internals and help other Python implementations to support the C API. -- One option for CPython would be to have a native HPy support, and emulate the legacy C API with something similar to what PyPy does with its cpyext module. That may make C extensions using the C API slower and may increase their memory usage. Victor On Wed, Dec 8, 2021 at 1:08 AM Guido van Rossum <gu...@python.org> wrote: > > Hi Victor, > > 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? Surely 5 release cycles would be enough to > completely remove the stable ABI and perhaps even the limited API in favor of > HPy? Or am I misunderstanding the place of HPy in the ecosystem? > > --Guido > > PS. Eric wrote an analyzer for C code and checked it in under > Tools/c-analyzer. This currently focuses on finding globals, but perhaps it > forms a good starting point for a linter for C extensions? -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GH7N6PKCM4775TRAPMCKJT4IRNG64KLP/ Code of Conduct: http://python.org/psf/codeofconduct/
