hpyproject / hpy

The tests use a trick to get a module spec from a shared object

Line 369 in f611473

spec = importlib.util.spec_from_file_location(name, so_filename)

This is fragile since it assumes the so_filename can be loaded as an extension module by the import mechanism. The so_filename for universal modules will end with hpy0.so. On CPython 3.10, print(importlib.machinery.EXTENSION_SUFFIXES) returns

['.cpython-310-x86_64-linux-gnu.so', '.abi3.so', '.so']

and on PyPy (after merging hpy-0.9) it prints

['.pypy39-pp73-x86_64-linux-gnu.so', '.hpy0-pypy39-pp73.so']

PyPy is more selective since we do not want to, by mistake, try to import a CPython c-extension and only allow importing legacy or c-api c-extensions. So that line in tests returns None. This causes a single test failure which was quite difficult to debug

hpy/test/test_hpymodule.py

Line 28 in f611473

assert mod.__name__ == mod.__spec__.name

Can we get the spec in some different way? We can just mock it completely. IIRC I used importlib.util.spec_from_file_location because that allowed me to not worry about how to construct a spec object.

It's fine to keep this code aroud. I needed a place to hang a comment in the PyPy code as to why I skipped the check. I will close this since there is really no need to do anything.

support uses a trick to get a module spec which fails on PyPy