Okay I just realized that I only fixed one file but grepping for METH_VARARGS I find a bunch more methods that have the same problem.

Does pyodide care about the difference between METH_VARARGS and METH_NOARGS?

I milestoned this as 3.5.1 as I think it is safe to do in a patch release and would like to get this out for pyodide ASAP, but do not want to hold 3.5.0 for it.

Does pyodide care about the difference between METH_VARARGS and METH_NOARGS?

No it doesn't since they both have signature PyObject* f(PyObject*, PyObject*).

If you want the details: Wasm32 uses 32 bit pointers so from the point of view of the wasm type system this has signature i32 f(i32, i32). It doesn't care about signed vs unsigned integers or pointers or anything, they all look the same. So it would be fine for wasm32 to declare a function as int f(int, int) and call it as PyObject* f(PyObject*, PyObject*).

Web assembly has a call_indirect instruction to call a function pointer. It takes as first argument the signature of the function pointer, as second argument the function pointer, and the remaining arguments are the arguments to the function pointer. These calls are type checked at runtime. If the signature indicated doesn't match the signature of the function, it throws a function signature mismatch error.

The problem here comes from trying to call a function with signature i32 f(i32) via a call_indirect instruction that asserts signature i32 f(i32, i32). The second argument to a METH_NOARGS function is always NULL and other architectures silently ignore it.

@hoodmane Have you overlooked METH_NOARGS functions in _tri_wrapper.cpp?

Have you overlooked METH_NOARGS functions in _tri_wrapper.cpp?

Looks like it, thanks.