I only reviewed the array API usage and the new utility wrappers/functions added in _lib/_array_api.py

Thanks Ralf! Have to admit I don't like where this is going, too, and I'm going to rework it all to avoid xp_* additions at an expense of some more meta-stuff.

I'm probably missing something very simple. So the point of array_api_strict is to provide a lowest common denominator for all array API libraries, and if tests pass with -b array_api_strict, they should pass under all backends, correct?

However IRL, after an update which makes tests pass under array_api_strict == 2, other backends fail left right and center with missing array API attributes and methods:

$ python dev.py test -s ndimage -b cupy -j 12
...
FAILED scipy/ndimage/tests/test_measurements.py::test_sum10[cupy] - AttributeError: module 'cupy' has no attribute 'bool'
FAILED scipy/ndimage/tests/test_interpolation.py::TestNdimageInterpolation::test_affine_transform26[2-cupy] - AttributeError: module 'cupy' has no attribute 'concat'
...

Am I missing something simple?

However IRL, after an update which makes tests pass under array_api_strict == 2, other backends fail left right and center with missing array API attributes and methods:

array_api_compatible parametrises tests with the raw (i.e. un-array_api_compat-wrapped) namespaces. If you need to use functions which exist in the standard but not in the main namespaces of the libraries we test with, you can use the pattern:

xp_test = array_namespace(x) # explain here why we need the wrapped namespace, e.g. # `cupy` needs `concat`
# use `xp_test` instead of `xp`

You should ensure that the arrays which are passed into the functions being tested are still created with the raw namespace xp rather than xp_test.

Sometimes it is better to avoid using this pattern by using NumPy functions and converting to xp at a later point.

That is for failures arising from the test functions themselves. If there are failures arising from the actual functions being tested, then something is going wrong with coercing to the wrapped namespace.

Can we please flag what's essential to change and what can be left for a follow-up? At this point I'm no longer clear on what is what.

Can we please flag what's essential to change and what can be left for a follow-up? At this point I'm no longer clear on what is what.

Sure, I'll have to take another look through your round of changes first.

OK, 5cfe3f0 addresses the two remaining comments.

TBH, I don't necessarily agree that the sumsq change is that useful, on the grounds that it adds essentially dead code. But this is not essential enough for me to argue, and it's changed in the above commit.

Let me know if you're happy with the result @lucascolley . The last thing is probably to squash the commits some --- 60+ commits is not useful here, so it's either a squash-merge (5kLOC) or separate into a pair of commits: one to add the delegation layer, the other to overhaul the tests (still 5kLOC). I'm leaning towards the second option, just so that the delegation stuff is more discoverable.

Rebased. It's five commits in the end: delegation, changes to ndimage itself, _lib testing infra, ndimage/testing refactors, and CI + mypy, all in separate commits.

Landed - thanks Evgeni!

Thanks for reviewing this Lucas!

@mdhaber if you are still interested in looking at generalising the delegation¹ infrastructure across here, special and beyond, that would be fantastic!