search

hpyproject / hpy

HPy: a better API for Python
https://hpyproject.org
MIT License
1.02k stars 52 forks source link

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

Closed mattip closed 8 months ago

mattip commented 8 months ago

The tests use a trick to get a module spec from a shared object https://github.com/hpyproject/hpy/blob/f6114734b4a5d03cfb9d24d3e8c71f77e8803881/test/support.py#L369

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 https://github.com/hpyproject/hpy/blob/f6114734b4a5d03cfb9d24d3e8c71f77e8803881/test/test_hpymodule.py#L28

steve-s commented 8 months ago

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.

mattip commented 8 months ago

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.