Fix METH_VARARGS method signatures

[hoodmane]

PR Summary

A bunch of functions are declared with METH_VARARGS calling convention which should have signature PYCFunction. However, they are declared instead with an extra PyObject* kwds argument as if they had METH_VARARGS | METH_KEYWORDS calling convention. They just ignore this argument.

I am coming from Pyodide. Web assembly has no native support for function pointer casting -- a function declared with a certain signature must be called with the same signature, or it will fail with RuntimeError: function signature mismatch. Emscripten has support for emulating function pointer casts which we are currently using, but it imposes a significant performance and stack space cost and we are trying to remove the pointer cast emulation pyodide/pyodide#1677. To do this, we need to patch Python packages so that they have function signatures that match the calling conventions they declare.

PR Checklist

Tests and Styling

• [N/A] Has pytest style unit tests (and pytest passes).
• [N/A] Is Flake 8 compliant (install flake8-docstrings and run flake8 --docstring-convention=all).

Documentation

• [N/A] New features are documented, with examples if plot related.
• [N/A] New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
• [N/A] API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).
• [N/A] Documentation is sphinx and numpydoc compliant (the docs should build without error).

[hoodmane]

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.

[github-actions]

Thank you for opening your first PR into Matplotlib!

If you have not heard from us in a while, please feel free to ping @matplotlib/developers or anyone who has commented on the PR. Most of our reviewers are volunteers and sometimes things fall through the cracks.

You can also join us on gitter for real-time discussion.

For details on testing, writing docs, and our review process, please see the developer guide

We strive to be a welcoming and open project. Please follow our Code of Conduct.

[tacaswell]

Does pyodide care about the difference between METH_VARARGS and METH_NOARGS?

[tacaswell]

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.

[hoodmane]

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.

[timhoffm]

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

[hoodmane]

Have you overlooked METH_NOARGS functions in _tri_wrapper.cpp?

Looks like it, thanks.