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/987#issuecomment-242996797,https://api.github.com/repos/pydata/xarray/issues/987,242996797,MDEyOklzc3VlQ29tbWVudDI0Mjk5Njc5Nw==,1217238,2016-08-28T20:19:18Z,2016-08-28T20:19:18Z,MEMBER,"Thanks @joonro, you are very kind!
I'm going to close this issue since I think we resolved the original question.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173494017
https://github.com/pydata/xarray/issues/987#issuecomment-242950283,https://api.github.com/repos/pydata/xarray/issues/987,242950283,MDEyOklzc3VlQ29tbWVudDI0Mjk1MDI4Mw==,1217238,2016-08-28T01:22:45Z,2016-08-28T01:22:45Z,MEMBER,"@joonro Yes, this does get messy. We'll eventually support indexing like `X[X > 0]` directly, which will help significantly.
In the meantime, you can still break things up onto multiple lines by saving temporary variables:
```
condition = X.loc[..., 'variable'].values > 0
X.loc[..., 'variable'].values[condition] = Y.loc[..., 'variable'].values[condition]
```
Using abbreviations like `...` for `:, :, :` (assuming `'variable'` is along the last axis) can also help.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173494017
https://github.com/pydata/xarray/issues/987#issuecomment-242938039,https://api.github.com/repos/pydata/xarray/issues/987,242938039,MDEyOklzc3VlQ29tbWVudDI0MjkzODAzOQ==,1217238,2016-08-27T20:07:45Z,2016-08-27T20:07:45Z,MEMBER,"Can you give an example of how you need to use .values in xarray
operations? Within xarray, we should be able to remove the need to use that.
On Sat, Aug 27, 2016 at 1:06 PM Joon Ro notifications@github.com wrote:
> Thanks a lot for the discussions. I agree it is very important to be
> consistent and explicit. Another thing was that sometimes .values makes a
> line of code really long - especially when I want to index a DataArray
> with another DataArray with some conditions, as I often have to use
> .values for each of them.
>
> Currently I do not have a good idea about how to improve this - I will
> report back if one occurs to me. Thanks again!
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> https://github.com/pydata/xarray/issues/987#issuecomment-242937958, or mute
> the thread
> https://github.com/notifications/unsubscribe-auth/ABKS1rjz_au5Uth5UsSgZpSqTXq7sYeyks5qkJi0gaJpZM4JuQKC
> .
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173494017
https://github.com/pydata/xarray/issues/987#issuecomment-242937188,https://api.github.com/repos/pydata/xarray/issues/987,242937188,MDEyOklzc3VlQ29tbWVudDI0MjkzNzE4OA==,1217238,2016-08-27T19:48:42Z,2016-08-27T19:48:42Z,MEMBER,"@darothen Let's discuss this over in #988.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173494017
https://github.com/pydata/xarray/issues/987#issuecomment-242800119,https://api.github.com/repos/pydata/xarray/issues/987,242800119,MDEyOklzc3VlQ29tbWVudDI0MjgwMDExOQ==,1217238,2016-08-26T17:34:37Z,2016-08-26T17:34:37Z,MEMBER,"> I wonder if it is reasonable to return a scalar when there is neither coords nor attrs associated with the return value, or it would be too much ad-hoc thing. For example, in the original example the return value was , which does not have any useful information.
This is a bad path to go down :). Now your code might suddenly break when you add a metadata field!
In principle, we could pick some subset of operations for which to always do this and others for which to never do this (e.g., aggregating out all dimensions, but not indexing out all dimensions), but I think this inconsistency would be even more surprising. It's pretty easy to see how this could lead to bugs, too. At least now you know you always need to type `.values` or `.item()`!
","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173494017
https://github.com/pydata/xarray/issues/987#issuecomment-242789058,https://api.github.com/repos/pydata/xarray/issues/987,242789058,MDEyOklzc3VlQ29tbWVudDI0Mjc4OTA1OA==,1217238,2016-08-26T16:51:02Z,2016-08-26T16:52:17Z,MEMBER,"I agree that this can be annoying. The downside in making this switch is that we would lose xarray specific fields like `coords` and `attrs` that are currently preserved, e.g.,
```
>>> array = xr.DataArray([1, 2, 3], coords=[('x', ['a', 'b', 'c'])])
>>> array
array([1, 2, 3])
Coordinates:
* x (x) |S1 'a' 'b' 'c'
>>> array[0]
array(1)
Coordinates:
x |S1 'a'
>>> array[0].coords['x'].item()
'a'
```
Also, strictly from a simplicity point of view for xarray, it's nice for every function to return fixed types.
NumPy solved this problem by creating it's own scalar types (e.g., `np.float64`) that define fields like `shape` and `dtype` while also subclassing Python's builtin numeric types. We _could_ do the same, but this could lead to a different set of subtle cross-compatibility issues.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173494017