PyCFunction_New and PyCFunctionNewEx are wrapped improperly for PyPy

[mattip]

The code here

pyo3/pyo3-ffi/src/methodobject.rs

Lines 195 to 199 in abe518d

	#[cfg_attr(PyPy, link_name = "PyPyCFunction_New")]
	pub fn PyCFunction_New(ml: *mut PyMethodDef, slf: *mut PyObject) -> *mut PyObject;
	#[cfg_attr(PyPy, link_name = "PyPyCFunction_NewEx")]
	pub fn PyCFunction_NewEx(

renames PyCFunction_New and PyCFunction_NewEx for PyPy. But they are macros to PyCMethod_New, like on CPython from here:

#define PyCFunction_New(ml, self) PyCFunction_NewEx((ml), (self), NULL)
#define PyCFunction_NewEx(ML, SELF, MOD) PyCMethod_New((ML), (SELF), (MOD), NULL)

and so will not have a mangled name. These are rarely used, but showed up in this PyPy issue, where it seems somehow the bindings for sr25519 use those interfaces.

[davidhewitt]

Thanks @mattip, the code you link above is guarded by #[cfg(not(Py_3_9))]; from memory this was different on PyPy 3.8 and older which would match the cfg.

I think it's due to the released py-sr25519-bindings using an extremely old PyO3 version (0.11.0 at time of their last release, which is over three years old at these point and predates a lot of the fixes for PyPy).

I've opened a downstream issue at polkascan/py-sr25519-bindings#16

I am also increasingly of the opinion that we should be gating the maximum Python version as well as the minimum, because I think py-sr25519-bindings should never have been allowed to compile against PyPy 3.10 (and the user would likely have then been prompted to open the issue against py-sr25519-bindings).

[mattip]

Thanks for taking a look and figuring out what went wrong.