Standard way of retrieving arrays that are wrapped by other arrays?

[vnmabus]

Some useful behavior that the standard array API makes possible is to create a "wrapper" structure that accept an array that follows the array API and returns a new array that follows the same API. Examples of possible (future) uses for that are:

• Masked array wrapping any compatible array.
• Sparse array wrapping any compatible array.
• Wrapper that provides support for units.
• Wrapper that provides support for metadata (such as names for dimensions or for individual rows/columns).

The array API allows all of these implementations to not know about each other, as long as they only rely on the operations provided by the standard. Thus, it would be possible to "stack" any of these wrappers in more or less any order.

However, for more complex behaviors it could be desirable to know about some properties of a particular wrapper in the "stack". For example, we may want to retrieve the mask for a masked array if any of the wrappers is a masked array. In this case, we would want to iterate over the array types in the "stack", and return the mask if any array has that property.

I was wondering if there were plans for facilitating this behavior in the future. I think that it should suffice just with standardizing a way to expose the wrapped array (e.g., exposing a wrapped_array: Array | None property), but maybe I am missing some cases that require a more robust routing mechanism.

[rgommers]

@vnmabus you may be interested in https://github.com/pydata/duck-array-discussion/issues. A lot of thought has been put into discussion there (and before that repo was created, on the Xarray repo IIRC).

There are no plans in this direction for the standard or a new implementation on top of it, AFAIK. It's a highly nontrivial topic; things like masked and sparse arrays do require their own implementation for both efficiency and semantics probably, they'll be difficult to layer on top.

[kgryte]

As I don't believe we'll be addressing this anytime soon, I'll go ahead and close this out. We can always revisit in the future should there be increased demand for this request among array libraries and their consumers.

[vnmabus]

Then maybe it should be closed as non-planned instead of completed, to prevent confusion.