If you want to try extending this support to other libraries which have a scipy namespace ... JAX in addition right now

Thanks for the suggestion @lucascolley ! This is indeed a nice exercise to check how general it is. The last commit adds the dispatch. Curiously,

$ python dev.py test -t scipy/signal/tests/test_signaltools.py::TestConvolve -v -b jax.numpy -v
...
FAILED scipy/signal/tests/test_signaltools.py::TestConvolve::test_basic[jax.numpy] - AssertionError: dtypes do not match.
FAILED scipy/signal/tests/test_signaltools.py::TestConvolve::test_same[jax.numpy] - AssertionError: dtypes do not match.
FAILED scipy/signal/tests/test_signaltools.py::TestConvolve::test_same_eq[jax.numpy] - AssertionError: dtypes do not match.
FAILED scipy/signal/tests/test_signaltools.py::TestConvolve::test_2d_arrays[jax.numpy] - AssertionError: dtypes do not match.
FAILED scipy/signal/tests/test_signaltools.py::TestConvolve::test_valid_mode2[jax.numpy] - AssertionError: dtypes do not match.
FAILED scipy/signal/tests/test_signaltools.py::TestConvolve::test_same_mode[jax.numpy] - AssertionError: dtypes do not match.
FAILED scipy/signal/tests/test_signaltools.py::TestConvolve::test_convolve_method[jax.numpy] - AssertionError: 
FAILED scipy/signal/tests/test_signaltools.py::TestConvolve::test_convolve_method_large_input[jax.numpy] - AssertionError: dtypes do not match.
======================================================================================= 8 failed, 8 passed in 3.27s ============================

Am adding @skip_xp_backends for now --- going forward I guess it would be nice to have a matching xfail_xp_backends.

I assume it's float32 vs float64? Which one is the result from convolve?

I assume it's float32 vs float64? Which one is the result from convolve?

There is at least one issue which looks like f32/f64 tolerance and there's a bunch of instances where jax returns float64 while cupyx and scipy preserve int64.

I'd be very wary of relaxing scipy tests on these. Either it's fixed upstream (if jax.scipy follows scipy), or we special-case it in tests (not in this PR I guess), or it just stays an xfail.

we should probably decide on what this variable should be called for consistency.

I'm not going to argue with whatever name you prefer. Mind pushing a tweak?

jax returns float64 while cupyx and scipy preserve int64.

As long as that is deliberate from scipy, sounds like a bug in jax.

If you still believe that scipy_namespace_for is broken, let me know if we need changes in special!

We should get CI green for NumPy first by being explicit about what dtype we expect (or using check_dtype=False if we don't care), then add a run of -t scipy/signal/tests/test_signaltools.py::TestConvolve to the Array API job

OK, reworked to mimic scipy.special: all delegation logic sits in a _support_alternative_backends.py file, and our original _signaltools.py is intact, as requested in #20772 (comment)

Have to admit I don't much like the sys.modules[func.__name__] = func dance (copycatted from scipy.special), but if it works it does I guess.
Overall this version does look a bit cleaner indeed.

One other simplification is about who is responsible for when an accelerator only implements a part of the scipy API. For instance, jax.scipy.signal.convolve2d only supports fillvalue=0. So the question is who is responsible for when a user feeds jax arrays and a nonzero fillvalue to scipy.signal.convolve2d? Previously this PR tried to intercept this case and raise a ValueError. This way, a user gets a traceback which points to scipy. The last commit removes this logic and makes {jax,cupy} arrays fall straight though to {jax.scipy,cupyx.scipy}.

Maybe we should just merge this

my term has just finished so I should have time to take a look at this

Addressed review comments.

Maybe we should just merge this since since there's a decent period before the next release to iron out any issues

Certainly would be happy to :-).

NB smoke-docs is going to fail left and right because of scipy/scipy_doctest#175, here and elsewhere.

CI is green modulo two known and unrelated issues (mypy and smoke-docs), there are two approvals, merging as approved and CI-green. Thanks to all reviewers!

Which of the prs stacked on this is the "next"?

#21713 is the closest "next", I'd say.
#21783 is largely independent.

After these two are in / are on their way in, will be able to move on to filters which accept windows, filter design and all that jazz.