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-873481034,https://api.github.com/repos/pydata/xarray/issues/3245,873481034,MDEyOklzc3VlQ29tbWVudDg3MzQ4MTAzNA==,14808389,2021-07-03T22:53:08Z,2021-07-03T22:53:08Z,MEMBER,"right, I would leave these methods to xarray extension libraries like `cupy-xarray` or `pint-xarray`. I assume you meant `.as_pint` because adding `.to_pint` does not make much sense: following the naming convention from above, `.to_*` should return the duck array, which would make it an alias of either `.data` or the duck array's constructor called on `.data`.","{""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-873480044,https://api.github.com/repos/pydata/xarray/issues/3245,873480044,MDEyOklzc3VlQ29tbWVudDg3MzQ4MDA0NA==,35968931,2021-07-03T22:41:39Z,2021-07-03T22:41:39Z,MEMBER,"Also I can add a `.to_pint()` method, but I don't really understand what the purpose would be? To be any use to users it would need to accept a `units` argument, but then it's basically just a less powerful version of `pint_xarray`'s `.quantify()` accessor method. Can you see any reason to add it @keewis ?","{""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-873222015,https://api.github.com/repos/pydata/xarray/issues/3245,873222015,MDEyOklzc3VlQ29tbWVudDg3MzIyMjAxNQ==,35968931,2021-07-02T19:43:04Z,2021-07-02T20:18:11Z,MEMBER,"I'm trying to implement this (I wanted pint-aware plotting to work) in #5568, but not 100% sure if I'm doing it right. ~~1) Do we want these `as_*`, `to_*` methods to live in `Variable` or `DataArray`?~~ 2) What about multiply-wrapped arrays? At the moment I have essentially ```python def as_numpy(self) -> T_DataArray: """""" Coerces wrapped data into a numpy array, and returns it wrapped in a DataArray. """""" data = self.data if isinstance(data, dask_array_type): return self.load() elif isinstance(data, cupy_array_type): return self.copy(data=data.get()) elif isinstance(data, pint_array_type): return self.copy(data=data.magnitude) elif isinstance(data, sparse_array_type): return self.copy(data=data.to_dense()) else: return self.copy(data=np.array(data)) ``` but do I actually want multiple passes, like ```python data = self.data if isinstance(data, dask_array_type): data = self.load().data if isinstance(data, cupy_array_type): data = data.get() if isinstance(data, pint_array_type): data = data.magnitude if isinstance(data, sparse_array_type): data = data.to_dense() return self.copy(data=np.array(data)) ``` 3) @jacobtomlinson currently `.values` will extract the values of a cupy array by special-casing it, but based on the above discussion do we actually want to break that in favour of getting them via `.to_numpy()` instead? 4) There are `_as_sparse` and `_to_dense` methods already, but they are private and only present on `Variable`. Should I expose them?","{""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-780923750,https://api.github.com/repos/pydata/xarray/issues/3245,780923750,MDEyOklzc3VlQ29tbWVudDc4MDkyMzc1MA==,14808389,2021-02-17T23:33:05Z,2021-02-17T23:33:05Z,MEMBER,"I agree, this would be useful. Ideally, that would be implemented by deferring to the data, for example by calling the data's `to_numpy` method (so duck array libraries or duck array integration libraries can customize that), falling back to `np.asarray(data)`.","{""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-780833545,https://api.github.com/repos/pydata/xarray/issues/3245,780833545,MDEyOklzc3VlQ29tbWVudDc4MDgzMzU0NQ==,2448579,2021-02-17T20:30:04Z,2021-02-17T23:22:19Z,MEMBER,"My impression was that the `as_*` methods would return xarray objects. So we could have DataArray methods ``` python def as_numpy(self): # needs cupy special handling data = self.data if isinstance(data, cupy_array_type): raise NotImplementedError else: return self.copy(data=np.array(data)) def to_numpy(self): """"""Coerces to and returns a numpy.ndarray"""""" return self.as_numpy().data ```","{""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-780798734,https://api.github.com/repos/pydata/xarray/issues/3245,780798734,MDEyOklzc3VlQ29tbWVudDc4MDc5ODczNA==,199813,2021-02-17T19:33:05Z,2021-02-17T19:33:05Z,NONE,"Is there any motion on this? This come up in relation to akward array today (see https://github.com/scikit-hep/awkward-1.0/issues/749 ). If xarray goes with the `to_numpy` spelling as well then all of {pandas, xarray, akwardarray} have the same spelling which is nice from the Matplotlib side of things. I think the `as_` vs `to_` distinction the ""to_"" makes more sense as it gets you out of xarray land and drops you back to raw numpy land.","{""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-662783599,https://api.github.com/repos/pydata/xarray/issues/3245,662783599,MDEyOklzc3VlQ29tbWVudDY2Mjc4MzU5OQ==,1217238,2020-07-23T01:58:00Z,2020-07-23T01:58:00Z,MEMBER,"Agreed! Sparse also needs a special case. On Wed, Jul 22, 2020 at 6:35 PM Deepak Cherian wrote: > IMO a good first pass for as_numpy would be to use np.asarray with a > special case for cupy where it would use .get. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > ","{""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-662778974,https://api.github.com/repos/pydata/xarray/issues/3245,662778974,MDEyOklzc3VlQ29tbWVudDY2Mjc3ODk3NA==,2448579,2020-07-23T01:35:08Z,2020-07-23T01:35:08Z,MEMBER,IMO a good first pass for `as_numpy` would be to use `np.asarray` with a special case for `cupy` where it would use `.get`.,"{""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-662602111,https://api.github.com/repos/pydata/xarray/issues/3245,662602111,MDEyOklzc3VlQ29tbWVudDY2MjYwMjExMQ==,3460034,2020-07-22T18:03:51Z,2020-07-22T18:03:51Z,CONTRIBUTOR,"> 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.)","{""total_count"": 2, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 1}",,484240082 https://github.com/pydata/xarray/issues/3245#issuecomment-662583820,https://api.github.com/repos/pydata/xarray/issues/3245,662583820,MDEyOklzc3VlQ29tbWVudDY2MjU4MzgyMA==,1217238,2020-07-22T17:26:59Z,2020-07-22T17:26:59Z,MEMBER,"> 3\. for now we are OK with special `as_sparse`, `as_cupy`, `as_pint` methods in xarray as long as all that logic is contained in one place: `as_duck_array.py`? +1 for `as_numpy()`, too 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()`.","{""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-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-662547659,https://api.github.com/repos/pydata/xarray/issues/3245,662547659,MDEyOklzc3VlQ29tbWVudDY2MjU0NzY1OQ==,2448579,2020-07-22T16:17:02Z,2020-07-22T16:17:02Z,MEMBER,"It seems like general consensus was (please correct me if any of this is wrong): 1. `.values` will return `np.asarray(obj.data)` and respect the underlying library's choices: this will raise an error with cupy and that's OK. 2. `.plot()` is a special case and should always coerce to numpy before passing data to matplotlib. plot currently uses `.values` so we should add a new function that always returns xarray objects with numpy arrays (with cupy as special case) and use that in plot. 3. for now we are OK with special `as_sparse`, `as_cupy`, `as_pint` methods in xarray as long as all that logic is contained in one place: `as_duck_array.py`?","{""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-661094939,https://api.github.com/repos/pydata/xarray/issues/3245,661094939,MDEyOklzc3VlQ29tbWVudDY2MTA5NDkzOQ==,14808389,2020-07-20T15:02:02Z,2020-07-20T15:02:02Z,MEMBER,"Sounds good. It might be worth discussing the general strategy for the support of this kind of duck array (sparse, cupy and others) in the dev call on Wednesday.","{""total_count"": 4, ""+1"": 4, ""-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-661062797,https://api.github.com/repos/pydata/xarray/issues/3245,661062797,MDEyOklzc3VlQ29tbWVudDY2MTA2Mjc5Nw==,14808389,2020-07-20T14:08:35Z,2020-07-20T14:09:33Z,MEMBER,"we currently don't really encourage this way of using accessors (especially using too many of these, see https://github.com/pydata/xarray/issues/1080#issuecomment-258582609 and https://github.com/pydata/xarray/issues/1080#issuecomment-258680571), but you *can* use `register_*_accessor` to register functions: ```python @xr.register_dataarray_accessor(""as_cupy"") def _(da): def as_cupy(self, ...): # ... return da return as_cupy ```","{""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-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-660209415,https://api.github.com/repos/pydata/xarray/issues/3245,660209415,MDEyOklzc3VlQ29tbWVudDY2MDIwOTQxNQ==,2448579,2020-07-17T16:34:30Z,2020-07-17T16:34:30Z,MEMBER,"I am unsure about automatic coercion for `.values`. I think we've trained users to expect numpy arrays from `.values` so `cupy` raising an error is a little unfriendly. OTOH it'd be nice to have something that is equivalent to `np.asarray(da.data)` but maybe we can expect users who want that to just type it out. But I think we should automatically coerce for `.plot` using `da.as_numpy().data` or something similar. We call `.compute()` on dask arrays anyway so it's consistent with that behaviour.","{""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 https://github.com/pydata/xarray/issues/3245#issuecomment-565757852,https://api.github.com/repos/pydata/xarray/issues/3245,565757852,MDEyOklzc3VlQ29tbWVudDU2NTc1Nzg1Mg==,6815844,2019-12-14T22:14:03Z,2019-12-14T22:14:03Z,MEMBER,"What is the best way to save `sparse` array into a disc? One naive way would be to use `stack` -> `reset_index`, but it flattened coordinates and if there is another variable that depends on these coordinates, they will be also flattened and may consume a lot of space. ","{""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-555650664,https://api.github.com/repos/pydata/xarray/issues/3245,555650664,MDEyOklzc3VlQ29tbWVudDU1NTY1MDY2NA==,5635139,2019-11-19T18:44:23Z,2019-11-19T18:44:23Z,MEMBER,"> `assparse` could read in at least two different ways, and one of which is not really appropriate. brilliant","{""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-555590777,https://api.github.com/repos/pydata/xarray/issues/3245,555590777,MDEyOklzc3VlQ29tbWVudDU1NTU5MDc3Nw==,1217238,2019-11-19T16:30:18Z,2019-11-19T16:30:18Z,MEMBER,"> Also isn't the function `astype` not `as_type`? Yes, but I think that's mostly works because it's so short. In general the rule is to use underscores when it improves clarity. `assparse` could read in at least two different ways, and one of which is not really appropriate.","{""total_count"": 3, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 3}",,484240082 https://github.com/pydata/xarray/issues/3245#issuecomment-555589399,https://api.github.com/repos/pydata/xarray/issues/3245,555589399,MDEyOklzc3VlQ29tbWVudDU1NTU4OTM5OQ==,2448579,2019-11-19T16:27:26Z,2019-11-19T16:27:26Z,MEMBER,"> it makes clear that the objects are still xarray objects This is a good point. I'm in favour of `as_sparse`, `as_dense`.","{""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-555588678,https://api.github.com/repos/pydata/xarray/issues/3245,555588678,MDEyOklzc3VlQ29tbWVudDU1NTU4ODY3OA==,1217238,2019-11-19T16:25:55Z,2019-11-19T16:25:55Z,MEMBER,"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.","{""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-555559603,https://api.github.com/repos/pydata/xarray/issues/3245,555559603,MDEyOklzc3VlQ29tbWVudDU1NTU1OTYwMw==,2448579,2019-11-19T15:28:53Z,2019-11-19T15:28:53Z,MEMBER,"I weakly prefer following the upstream API: `as_sparse` and `todense`. though `to_sparse`,`to_dense` and `to_numpy_data` would be more consistent? Also isn't the function `astype` not `as_type`?","{""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-554795681,https://api.github.com/repos/pydata/xarray/issues/3245,554795681,MDEyOklzc3VlQ29tbWVudDU1NDc5NTY4MQ==,6815844,2019-11-17T22:38:51Z,2019-11-17T22:38:51Z,MEMBER,"Do we arrive at the consensus here for API to change the sparse or numpy array? xref #3542 To make it sparse array, `to_sparse()` would be better? How about or `as_sparse()`? + `to_sparse()` is probably consistent to `todense()` method + `as_sparse()` sounds similar to sparse's function, e.g. `sparse.as_coo` To change the backend back from sparse array, `to_dense()` would be better? FYI, sparse uses `todense()`. I personally like `as_sparse` or `as_numpy` (or `as_dense`?), which sounds similar to `as_type`, which gives xarray object not dtype itself.","{""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-539215442,https://api.github.com/repos/pydata/xarray/issues/3245,539215442,MDEyOklzc3VlQ29tbWVudDUzOTIxNTQ0Mg==,1634164,2019-10-07T21:37:53Z,2019-10-07T21:37:53Z,NONE,"As far as I can tell, the proposal here will require either ```python s = pd.Series(...) xr.DataArray.from_series(s).to_series() ``` or: ```python xr.DataArray.from_series(s, sparse=True).to_dense().to_series() ``` For any code that can't guarantee sparse/non-sparse input, the first will fail sometimes, so it will always be necessary to write the latter everywhere, which IMO is unnecessarily verbose.","{""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-524488632,https://api.github.com/repos/pydata/xarray/issues/3245,524488632,MDEyOklzc3VlQ29tbWVudDUyNDQ4ODYzMg==,1217238,2019-08-23T23:08:28Z,2019-08-23T23:08:28Z,MEMBER,"Xarray's .data is basically the equivalent of pandas's .array. On Fri, Aug 23, 2019 at 2:44 PM Maximilian Roos wrote: > I do think the pandas approach is pretty good here - don't break anything > relying on .values - instead have .array to get the backing array (in > whatever form it might be), and to_numpy() coercing to a raw numpy array > > ref > https://pandas.pydata.org/pandas-docs/stable/whatsnew/v0.24.0.html#accessing-the-values-in-a-series-or-index > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > , > or mute the thread > > . > ","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484240082 https://github.com/pydata/xarray/issues/3245#issuecomment-524456277,https://api.github.com/repos/pydata/xarray/issues/3245,524456277,MDEyOklzc3VlQ29tbWVudDUyNDQ1NjI3Nw==,5635139,2019-08-23T20:44:53Z,2019-08-23T20:44:53Z,MEMBER,"I do think the pandas approach is pretty good here - don't break anything relying on `.values` - instead have `.array` to get the backing array (in whatever form it might be), and `to_numpy()` coercing to a raw numpy array ref https://pandas.pydata.org/pandas-docs/stable/whatsnew/v0.24.0.html#accessing-the-values-in-a-series-or-index","{""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-524410610,https://api.github.com/repos/pydata/xarray/issues/3245,524410610,MDEyOklzc3VlQ29tbWVudDUyNDQxMDYxMA==,1217238,2019-08-23T18:09:25Z,2019-08-23T18:09:25Z,MEMBER,"The main downside of `to_numpy()` is that it isn't obvious whether the result should be a DataArray containing a NumPy array or a raw NumPy array. In particular, pandas uses `to_numpy()` for converting into a raw NumPy, which is the opposite of our intent here.","{""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-524408760,https://api.github.com/repos/pydata/xarray/issues/3245,524408760,MDEyOklzc3VlQ29tbWVudDUyNDQwODc2MA==,2448579,2019-08-23T18:03:17Z,2019-08-23T18:03:17Z,MEMBER,:+1: I think `to_numpy()` would be good.,"{""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-524407909,https://api.github.com/repos/pydata/xarray/issues/3245,524407909,MDEyOklzc3VlQ29tbWVudDUyNDQwNzkwOQ==,1217238,2019-08-23T18:00:45Z,2019-08-23T18:00:45Z,MEMBER,"> * Should we formalize the convention that `.values` always return a numpy array i.e. it will call `todense()` implicitly and that `.data` will always return the underlying container: sparse/dask etc.? I think `.values` should either return a NumPy array or raise an exception, based upon whether or not the underlying duck array supports coercion with `np.array()`. We should have a separate API (maybe `.to_dense()` or `.to_numpy_data()`?) for explicitly converting into NumPy arrays. This should not be called automatically inside xarray. Basically, we should leave the decision about whether automatic coercion is safe up to the authors of duck array libraries.","{""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-524388072,https://api.github.com/repos/pydata/xarray/issues/3245,524388072,MDEyOklzc3VlQ29tbWVudDUyNDM4ODA3Mg==,2448579,2019-08-23T16:57:10Z,2019-08-23T16:57:10Z,MEMBER,"The better way to phrase this is: 1. Should we formalize the convention that `.values` always return a numpy array i.e. it will call `todense()` implicitly and that `.data` will always return the underlying container: sparse/dask etc.? 2. Should we call `todense()` automatically in `plot()` the same way we do `compute()`?","{""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-524125410,https://api.github.com/repos/pydata/xarray/issues/3245,524125410,MDEyOklzc3VlQ29tbWVudDUyNDEyNTQxMA==,1217238,2019-08-23T00:19:15Z,2019-08-23T00:19:15Z,MEMBER,I think it is intentional for automatic coercion to NumPy arrays to fail. Making `plot()` and `.values` work should probably require explicitly writing `datarray.to_dense()` first.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484240082