gh-1063: Default to numpy for all unrecognised array backends#1065
Conversation
This reverts commit 690d57c.
| @pytest.mark.skipif(not HAVE_JAX, reason="test requires jax") | ||
| def test_rng_dispatcher_jax() -> None: | ||
| import jax.numpy as jnp | ||
| import jax.numpy as jnp # ty: ignore[unresolved-import] |
There was a problem hiding this comment.
Trying to work out why we need now 🤔
There was a problem hiding this comment.
Yes, I'm not sure why this wasn't a problem before. I guess we haven't ran ty against this file before? Shoudl we just ignore that rule everywhere?
There was a problem hiding this comment.
It's probably just that ty has updated since we last ran it. I think leave ty on for now as it's still early in development.
| compare.assert_array_equal(old, new) | ||
|
|
||
|
|
||
| @pytest.mark.skipif(not HAVE_ARRAY_API_STRICT, reason="test requires array_api_strict") |
There was a problem hiding this comment.
Do we need this now from the work of this PR or is this something previously missed?
There was a problem hiding this comment.
I think this was previously missed. I just tried to run with ARRAY_BACKEND=numpy and got an error.
There was a problem hiding this comment.
Not sure how we missed that. Are we missing something in our CI for this?
There was a problem hiding this comment.
If we always install array-api-strict, then it'll pass.
There was a problem hiding this comment.
I know. But we could have a separate test to ensure we're testing it properly. I'm thinking something along the lines of #670
2 participants
Description
array_api_strictif it isn't installed.Also adds CuPy as a library for testing to check this new functionality.Closes: #1063
Changelog entry
Changed: Instead of raising an exception, we now default to NumPy if an array backend is not supported.
Checks