Open
Description
I'm starting to see multiple Array API compliant libraries that are just thin wrappers around another arbitrary Array API compliant library:
- @mdhaber's marray
- @lucascolley's quantity-array
- I'm deliberately keeping Dask out of scope for this issue, as there is a lot of nuance involved in it.
- xarray's wrapping design also predates the Array API and xarray is not (today) Array API compatible, but I can see it joining the fray soon.
These libraries currently fail to work with array-api-compat
, array-api-extra
, or anything that relies on them (like scipy) except in the most basic use cases, e.g. wrapping around a writeable numpy or cupy array.
These are the reasons I could find so far:
array_api_compat.is_writeable_array
blindly returns True for unknown namespaces. This is problematic also when wrapping around read-only numpy arrays.array_api_compat.is_lazy_array
incorrectly returns False for wrapped Dask. This will lead to major performance issues.xpx.at
,xpx.apply_where
, andxpx.lazy_apply
have special casing for Dask which won't be triggered when Dask is wrapped. You can't just changearray_api_compat.is_dask_array
to return True for wrapped dask objects, because there are a wealth of dask-specific calls (da.map_blocks
, passing the arrays to a@delayed
function) that won't work out of the box.- The same functions, plus
nunique
, have special casing for JAX. Again, there are jax-specific function calls e.g.jax.pure_callback
that won't accept wrapped arrays. - Delegated functions (
xpx.pad
) should work thanks to their generic code path, but they are untested; so for examplepad
on PyTorch works due to special casing, but there are no tests that verify that the generic implementation ofpad
applied to a wrapper around PyTorch will work.