Make numexpr work under Pyodide/WebAssembly

[ariostas]

I want to use numexpr for one of the projects that I work with, and I need it to still be able to run on Pyodide. However, there are no Pyodide wheels for numexpr. I looked into it a bit to see how much it would take to get this to work, and it turned out that it was fairly straightforward. Only some minor tweaks were needed to make sure that threading was not a problem in Pyodide, and a few tests needed to be skipped. I also added a CI job so that it starts building and testing the Pyodide wheels. These wheels can now also be uploaded to PyPI (see PEP 783).

I used assistance from Claude Code for this PR. I attached the more detailed description from Claude below.

🤖 AI text below 🤖

NumExpr does not currently work under Pyodide/WebAssembly. This makes it work, and adds CI coverage so it keeps working.

exit(-1) when the thread pool cannot be created

init_threads called exit(-1) if pthread_create failed, which terminates the host process rather than the library. Emscripten fails every thread creation with EAGAIN, so import numexpr with OMP_NUM_THREADS or NUMEXPR_MAX_THREADS set, or any set_num_threads(n) with n > 1, tore down the whole interpreter.

It now falls back to serial evaluation instead:

• init_threads returns -1 and leaves gs.nthreads == 1 when the pool cannot be brought up, unwinding any threads that did start.
• The pool shutdown sequence in numexpr_set_nthreads is factored out into join_threads so the partial-failure path can reuse it.
• The signal-mask calls and pthread_join now warn instead of exiting, so no exit() calls remain in the extension.
• numexpr.nthreads is read back from the VM after initialization so it reports the pool that actually exists rather than the one that was requested.

This part is not WebAssembly-specific: a library should not take down a CPython process because it could not get a thread.

print_versions() on platforms with no dedicated CPUInfo subclass

cpu.info resolved through CPUInfoBase.__getattr__ to lambda: None, so cpu.info[0] raised TypeError, which the surrounding except KeyError did not catch. This affects Emscripten, but also FreeBSD and AIX. CPUInfoBase now carries an info = [] default and the guard catches TypeError/IndexError as well.

Skipping tests that need processes or threads

Eight tests spawn an interpreter or start OS threads to test what they test, so they fail rather than skip on runtimes that have neither:

• test_locals_clears_globals needs a top-level frame, so it has to run in a separate interpreter.
• test_threading_config.test_max_threads_{set,unset} test import-time configuration, which needs a fresh process to re-run the extension's init.
• test_threading.* needs real threads.
• test_subprocess.test_multiprocess needs the _multiprocessing extension.

They are now gated on capability constants. Note that _thread and os.fork are both present but non-functional under Emscripten, hence the platform check for processes and an actual probe for threads, which is what CPython's own test suite does. The skips use unittest.skipUnless rather than pytest markers so they also work under numexpr.test(), which runs the suite through unittest. Nothing is skipped on the existing platforms.

CI

Adds a Pyodide entry to the wheel matrix. cibuildwheel provides the Emscripten SDK and the Pyodide runtime and runs test-command inside it, so these wheels are exercised under WebAssembly rather than only built. No changes to the cibuildwheel configuration in pyproject.toml were needed.

This requires cibuildwheel 4.x, which does not support Pyodide in the 3.1.3 previously used, so the action is bumped for every platform. Two consequences worth flagging for review:

• CIBW_ENABLE: cpython-freethreading is removed. That enable group no longer exists in 4.x, because free-threaded builds are on by default, and passing it is a hard error. The free-threaded targets are unaffected: cp314t is still built and cp313t still skipped via pyproject.toml.
• CPython 3.15 is in cibuildwheel's default target set, so cp315 and cp315t wheels are now produced for every platform. This is not gated behind cpython-prerelease and cannot be disabled through CIBW_ENABLE; it would need a skip entry in pyproject.toml if that is not wanted.