Let's take a couple of example files and see what it would take to make them reusable and move them into the HPy repository for ANY interpreter host to build upon.

https://foss.heptapod.net/pypy/pypy/-/blob/branch/hpy/pypy/module/_hpy_unive...

According to my IDE, most of the imports in e.g. interp_list.py are not used.

Imagine that we replaced all of them with:

from interpreter_context.apiset import API, handles, pytypes

W_ListObject would be imported from pytypes.

As an interpreter host vendor, I'd just implement space, API, handles, pytypes and I could reuse interp_list as-is. The PyPy implementation of the "interpreter" package would just rename the modules from pypy.module. _hpy_universal

According to my IDE, these SAME imports would make interp_number and interp_tuple "just work" as well.

To implement interp_long, I need to inject a new dependency, called "typesystem" which is a generalization of rffi and lltype.

interp_builder and interp_tracker need only a "Root" object injected.

A couple of the files need Unicode stuff injected.

There is an implicit dependency on cparser which would need to be dealt with one way or another...using a C Parser seems a bit like overkill given a) Python has type annotations and b) all of the declarations are machine-generated anyhow. But if CParser is a hard requirement then I guess it would become a dependency of the HPyHostAPI package.

My last thought is that perhaps the CPython Universal implementation could be written in Python instead of C. Of course it would run slower, but development of it would tend to maintain feature parity with PyPy "automatically".

Or you could do it in Python for the next year or two and then go back and optimize it back to C once HPy is finalized.

• Paul