html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/3245#issuecomment-662555403,https://api.github.com/repos/pydata/xarray/issues/3245,662555403,MDEyOklzc3VlQ29tbWVudDY2MjU1NTQwMw==,1610850,2020-07-22T16:31:14Z,2020-07-22T16:31:14Z,CONTRIBUTOR,Thanks for writing that up @dcherian. Sounds good to me!,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484240082
https://github.com/pydata/xarray/issues/3245#issuecomment-661087703,https://api.github.com/repos/pydata/xarray/issues/3245,661087703,MDEyOklzc3VlQ29tbWVudDY2MTA4NzcwMw==,1610850,2020-07-20T14:49:55Z,2020-07-20T14:49:55Z,CONTRIBUTOR,"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?","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484240082
https://github.com/pydata/xarray/issues/3245#issuecomment-661050583,https://api.github.com/repos/pydata/xarray/issues/3245,661050583,MDEyOklzc3VlQ29tbWVudDY2MTA1MDU4Mw==,1610850,2020-07-20T13:47:45Z,2020-07-20T13:47:45Z,CONTRIBUTOR,"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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484240082
https://github.com/pydata/xarray/issues/3245#issuecomment-660201690,https://api.github.com/repos/pydata/xarray/issues/3245,660201690,MDEyOklzc3VlQ29tbWVudDY2MDIwMTY5MA==,1610850,2020-07-17T16:22:06Z,2020-07-17T16:22:06Z,CONTRIBUTOR,"@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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484240082