issue_comments

One question about as_numpy: should it convert pint arrays into NumPy by stripping units? Or should it convert the arrays underlying pint and keep the units? I guess the first would probably make more sense for DataArray.as_numpy(). The second behavior could be achieved with DataArray.pint.as_numpy().

This brings up a point I was wondering about as well: how should these as_*() methods relate to multiply-nested arrays? (Not sure if best to discuss that here or new issue.)

Thanks for writing that up @dcherian. Sounds good to me!

Thanks @keewis. I did consider that but I assumed that kind of thing wouldn't be encouraged. Happy to go down that path, but I wonder if life would be easier if there were an extension API for this purpose.

I was thinking of something along these lines which would help keep things in check.

```python @xr.register_dataarray_as_method("cupy") class CupyAsMethod: def to_cupy(self): """Convert all data arrays to cupy."""

    for var in self.data_vars: 
        self.data_vars[var].data = cp.asarray(self.data_vars[var].data)

    return self

def to_numpy(self):
    """Convert all data arrays to numpy."""

    for var in self.data_vars: 
        self.data_vars[var].data = self.data_vars[var].data.get()

    return self

```

There would need to be some logic around dispatching as_numpy to CupyAsMethod.as_numpy, but only if the underlying data is cupy.

Perhaps some is_numpy, is_cupy boolean attributes would be useful?

I could go as you suggest and use the current accessor tooling to test this functionality out. Then upstream it into something more maintainable if it works out ok?

Given the current guidance in #4212 is to aim for cupy to mostly be handled via accessors I wonder if xarray could be extended a little further to allow as_ methods to be registered in the same way as accessors.

Currently with the accessor model a user would need to do something like ds.cupy.as_cupy and ds.cupy.as_numpy. When casting a DataSet or DataArray to use cupy under the hood I expect folks would look for a top level as_cupy method. And once it has been cast it would need a cupy specific as_numpy method to be able to cast back.

Enabling accessors to register as_ methods at the top level would really help neaten this up.

@dcherian pointed me over here after I raised #4234.

I like as_sparse and as_dense, because it makes clear that the objects are still xarray objects. I agree with @fujiisoup that to_sparse``todense could be confused to return sparse arrays directly.

I very much agree with this reasoning. to_ sounds like it is converting the whole thing to another type. as_ sounds like it is remaining the same but something about it (the underlying array type) is changing.

Basically, we should leave the decision about whether automatic coercion is safe up to the authors of duck array libraries.

I also agree with this reasoning. In cupy many things will break because np.asarray(cupy_array) will raise. So something like cupy_da.plot() will raise. But the exception will be ValueError: object __array__ method not producing an array which isn't particularly user friendly in this case.

For cupy I do think that automatic coercion to numpy for .values and plot() is a reasonable thing to do. But I understand that may not be true for all duck type arrays.

One suggestion is to add an accessor to make things explicit. So it would become cupy_da.cupy.plot(). Where this plot function coerces to numpy and then calls the upstream plot method. However this feels less satisfying.