If all the functions in the array namespace accept NumPy arrays as input, this does seem like a minor issue. I guess there are some things which will just be wrong though, likex[idx].__array_namespace__().

Would it be an option to return a subclass ofnp.ndarray for decompressed slices, and implement== (and things like__array_namespace__) accordingly?

That is also quite a good idea thanks very much. I have opened a ticketBlosc/python-blosc2#464 (comment). Will try to work on it in the medium term and focus on the rest of the array-api suite for the moment.

Please don't hesitate reaching out, here or in thearray-api-tests repo for specific issues with the test suite!

If all the functions in the array namespace accept NumPy arrays as input, this does seem like a minor issue. I guess there are some things which will just be wrong though, like x[idx].array_namespace().

The problem with this is mainly that we don't allow "promotion", i.e. no way to mix different array types in__array_namespace__().
So subclass that does nothing but change the namespace can solve this, although, I can't say I am a big fan of an unnecessary subclass that might confuse things.

(The question is whether you want users to mix NumPy and blosc arrays, because if you do, users may run into this issue whether the subclass exists or not. And the only fix is to allow array-namespace to figure things out. That isn't hard, Array API just didn't want to add the complexity.)

EDIT: If you are happy with the subclass, fine, it's avery simple one. But it leaves me a bit unsatisfied because I think it is an inelegant solution for what is an Array API issue/limitation.

Yeah, we have discussed that internally, and I am not a big fan of the subclass either, precisely because I feel it inelegant too, but also because it adds another class that the user has to know about. For the time being we will just skip the tests that are related with this. Perhaps in the future we can come with a solution that satisfies most of us.

At a guess, that's hypothsis generating a too-large array to test. Note that assertions inarray-api-tests typically loop over array elements in python, so there's overhead.

Try passing--disable-deadline to the pytest invocation.

I imagine this is just a question of whether current adoption is widespread enough to justify requiring it from all compliant implementations.

At the moment, libraries, such as NumPy, JAX, Torch, and Dask, don't support ashape kwarg inarange andlinspace, so it would likely be an uphill battle standardizing. In searching on the NumPy issue tracker, I wasn't able to find a feature request for addingshape to eitherarange orlinspace, so it is not clear there is user demand for this atm.

Could blosc evaluatexp.reshape(xp.arange(...), shape) lazily as equivalent toxp.arange(..., shape=shape)@FrancescAlted ?

Ok, that looks like a good idea, and performance wise, the difference is not that much:

In [1]: import blosc2In [2]: %time a = blosc2.lazyexpr("arange(100_000_000)")CPU times: user 27.7 ms, sys: 22.7 ms, total: 50.4 msWall time: 45.5 msIn [3]: %timeit blosc2.reshape(a, (10_000, 10_000))700 ms ± 2.72 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)In [4]: %timeit blosc2.arange(100_000_000, shape=(10_000, 10_000))686 ms ± 2.73 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)In [5]: %timeit blosc2.arange(100_000_000).reshape((10_000, 10_000))829 ms ± 1.89 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

great! I guess this is why the standard includesreshape as a function rather than an array object method.