MAINT: Ensure that parsing errors are passed on even in tests. - #11173

Multiline comments like so:

/*
 * blah
 * blah
 */

done

Not sure this comment is necessary - any PyObject * allocation can fail due to memory limits, so we should always check results like this.

Well, I'll maybe leave this as a breadcrump for the future - or to remind myself of hours waster...

In multiarraymodule.c we use

#if defined(NPY_PY3K)
#define RETVAL(x) x
PyMODINIT_FUNC PyInit_multiarray(void) {
#else
#define RETVAL(x)
PyMODINIT_FUNC initmultiarray(void) {
#endif

would be nice to have a consistent macro here

Wasn't aware of that - like it much better, so will change.

Either:

• Testing PyErr_Occurred() is pointless
• There is a bug in PyUFunc_FromFuncAndDataAndSignature which fails to set an exception correctly

I'm assuming the former, meaning you can just call PyErr_Print() unconditionally

Maybe I was being overly defensive here, but the docs for PyErr_Print are very specific that one should be sure an error is set otherwise bad things happen. Normally, of course, we'd just return NULL here and let downstream take care of it, but here we're setting a new error and I thought it was useful to at least print the old one.

But if you think this really doesn't make sense, I'll take it out (I had it out when I first added the return value).

I suppose my point is that addUfuncs() < 0 is already our test to be sure that an error is set. If we returned -1 but forgot to set an error, that's a bug.

Also it seems that PyErr_Print is perfectly ok with there being no error anyway. So I'd say keep the PyErr_Print(), but drop the condition guarding it.

So much for trusting the documentation... OK, condition dropped.

In principle we should be checking the return value of PyDict_SetItemString too, but I'm happy for you to declare that out of scope for this PR.

Yes, let's do that - I think if we're just calling standard python interface routines, we can be a bit more cavalier; we mostly need to guard against our own mistakes!