Request: Support for dpnp

[Nin17]

dpnp aims to be a drop-in replacement for NumPy and is already compatible with the 2024.12 version of the array api standard. As such it should be a relatively simple addition.

I'm mainly asking as I'd like the inspection helper functions array_api_compat.is_dpnp_array and array_api_compat.is_dpnp_namespace to be included.

[lucascolley]

cc @antonwolfy @vlad-perevezentsev

would someone be interested in contributing this?

[ev-br]

To double-check: it looks that from the -compat perspective, dpnp is similar to jax: the Array API support lives in the package itself, and array-api-compat only has the two helper functions:

array-api-compat/src/array_api_compat/common/_helpers.py

Line 431 in 2865123

def is_jax_namespace(xp: Namespace) -> bool:

and

array-api-compat/src/array_api_compat/common/_helpers.py

Line 217 in 2865123

def is_jax_array(x: object) -> TypeIs[jax.Array]:

Meanwhile ndonnx is similar but -compat does not have matching is_ndonnx_* functions. Thus I wonder why we need to special-case some array providers and not others. A main question I suppose is how is -compat layer useful to dpnp if it's already fully compatible @Nin17 ?

OTOH there's no problem adding these two functions to -compat if it's anyhow useful.

[lucascolley]

Meanwhile ndonnx is similar but -compat does not have matching is_ndonnx_* functions. Thus I wonder why we need to special-case some array providers and not others. A main question I suppose is how is -compat layer useful to dpnp if it's already fully compatible @Nin17 ?

OTOH there's no problem adding these two functions to -compat if it's anyhow useful.

I think the main two reasons are:

• a downstream library wants to run library X through their test-suite
• a downstream library wants to write to the standard whilst also having special-cases for library X in production code

I guess neither of those have happened yet for ndonnx (or people have been happy to roll their own).

[Nin17]

Meanwhile ndonnx is similar but -compat does not have matching is_ndonnx_* functions.

Those functions are included:

array-api-compat/array_api_compat/common/_helpers.py

Line 174 in 52e01be

def is_ndonnx_array(x: object) -> TypeIs[ndx.Array]:

array-api-compat/array_api_compat/common/_helpers.py

Line 376 in 52e01be

def is_ndonnx_namespace(xp: Namespace) -> bool:

A main question I suppose is how is -compat layer useful to dpnp if it's already fully compatible @Nin17 ?

• a downstream library wants to write to the standard whilst also having special-cases for library X in production code

Essentially that, I have an array api standard compliant implementation, but for performance reasons for libraries that support as_strided/sliding_window_view I want to use an alternative implementation. I could just implement my own check, but thought seeing as you already include similar functions for jax, ndonnx and pydata/sparse it may as well be included here.

[ev-br]

Ah, thanks, don't know how I missed these two.

Essentially that, I have an array api standard compliant implementation, but for performance reasons for libraries that support as_strided/sliding_window_view I want to use an alternative implementation. I could just implement my own check, but thought seeing as you already include similar functions for jax, ndonnx and pydata/sparse it may as well be included here.

PR welcome!