Thanks @zebreus. This change seems reasonable to me, and can be merged as is I think.

I see a CPython interpreter can be built on WASIX, so note that the NumPy test suite has a lot of test skips for WASM, controlled by this boolean:

IS_WASM = platform.machine() in ["wasm32", "wasm64"]

Those skips are for things that don't work in Emscripten-based interpreters like Pyodide (file system access, subprocess invocations, etc.). If WASIX/wasmer or other such things are going to offer more comprehensive Python support, we may need to distinguish between these different WASM flavors better.

Any reason why this PR is Draft?

Thanks for the quick feedback @rgommers .

This PR is still a draft because I didn't come around to verify that everything is working as expected with WASIX last week. I have now done so, and I am marking this as ready.

For now, the test skips are still needed. While Python on WASIX supports subprocess, a few other things are still missing. Additionally, running programs with dlopen support currently requires wasmer and wasix-libc builds from a specific branch, so they are not yet suitable for integration into an automated test suite.