Open steve-s opened 1 year ago
Thanks for starting this.
Upstreaming HPy support to CPython can have two main forms:
It would be nice to have CPython do "the same thing" that PyPy and GraalPython do. I guess this means shipping a backend as part of CPython. Do we have good test coverage for the backend in the test suite?
export dummy symbols for the few CPython APIs known to be used in the shim
This would seem to be the easiest path, especially since both PyPy and GraalPython already export many CPython APIs. Once they could drop C-API support (in a future where HPy is used everywhere), we would just repurpose the existing functions to stubs.
(This came up from a short discussion with Steve Dower at EuroPython)
One of the things suggested in https://github.com/hpyproject/hpy/issues/421 is to upstream HPy support to CPython. Note that this whole issue is about HPy universal extensions. Extensions built with CPython ABI just work on CPython by definition.
Upstreaming HPy support to CPython can have two main forms:
For the time being, the second option seems as more realistic for upstreaming to CPython in short term future.
The obvious way to implement the second option it is to extend the Python's import machinery to recognize HPy extensions and when loading such extension it would delegate to the HPy universal package. If the HPy universal package is not installed, it would tell the user to do so. This solution has two main drawbacks:
Another approach that would require only very minimal changes to CPython:
PyInit_mymodule
entry-point alongside the standard HPy init function. The CPython entry-point would load HPy package and kick-start the loading of the HPy extension via the HPy package. (If the HPy package was missing it would tell the user what to do). Other Pythons would just ignore this entry-point (possibly even some future CPython versions with native HPy support would ignore it).Some technical issues that we would need to solve:
dlsym
to dynamically load the necessary symbols (on all supported platforms)?