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/692#issuecomment-168527832,https://api.github.com/repos/pydata/xarray/issues/692,168527832,MDEyOklzc3VlQ29tbWVudDE2ODUyNzgzMg==,5635139,2016-01-03T18:41:04Z,2016-01-03T18:41:04Z,MEMBER,"OK, I guess that's how I think about the distinction with Indexes - they're role is for selection in one dimension, each. 

Maybe this is a more conceptual issue then...
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,124441012
https://github.com/pydata/xarray/issues/692#issuecomment-168516553,https://api.github.com/repos/pydata/xarray/issues/692,168516553,MDEyOklzc3VlQ29tbWVudDE2ODUxNjU1Mw==,1217238,2016-01-03T16:35:57Z,2016-01-03T16:35:57Z,MEMBER,"> Am I missing something more fundamental?

You're right that this won't come up in many circumstances. It's only that, like with numpy, we try to make xray operations always generalize to multi-dimensional arrays.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,124441012
https://github.com/pydata/xarray/issues/692#issuecomment-168355707,https://api.github.com/repos/pydata/xarray/issues/692,168355707,MDEyOklzc3VlQ29tbWVudDE2ODM1NTcwNw==,5635139,2016-01-02T01:46:09Z,2016-01-02T01:46:09Z,MEMBER,"That did fix it! Apologies for not testing on master.

On the broader issue, I hadn't thought of the need to expand dims / indexes to more than one dimension. I was thinking that there would be a 1D index per dim, and the result of slicing a multidimensional array would be the intersection of each dim's slice. Am I missing something more fundamental?
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,124441012
https://github.com/pydata/xarray/issues/692#issuecomment-168354211,https://api.github.com/repos/pydata/xarray/issues/692,168354211,MDEyOklzc3VlQ29tbWVudDE2ODM1NDIxMQ==,1217238,2016-01-02T01:11:13Z,2016-01-02T01:11:37Z,MEMBER,"The challenge is that the pandas Index has a much smaller API than numpy/dask.array. For example, it doesn't have a `transpose` method that accepts an `axis` argument. As another example, there's no equivalent of `numpy.stack` that would expand the contents of an Index to multiple dimensions. So we're pretty much stuck converting to numpy for these sort of situations.

I'm all for preserving indexes (including all their quirks) in situations where it's possible. And in other cases, we should fall back to numpy arrays with dtype=object holding appropriate scalars.

As for this particular issue, have you tested this after the changes in https://github.com/xray/xray/pull/691? I actually can't reproduce this issue on master.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,124441012
https://github.com/pydata/xarray/issues/692#issuecomment-168348251,https://api.github.com/repos/pydata/xarray/issues/692,168348251,MDEyOklzc3VlQ29tbWVudDE2ODM0ODI1MQ==,5635139,2016-01-01T23:07:06Z,2016-01-01T23:07:06Z,MEMBER,"Yeah, that seems fairly hacky (presumably this is would still be a problem if we have `nim > 2`?) 

From my POV I'm still thinking whether XRay can fall back to pandas indexing more extensively (as discussed [here](https://github.com/xray/xray/issues/645#issuecomment-164635815)). Dims could be stored as Pandas indexes rather than dask / numpy arrays, and the (much cleaner) XRay indexing API could be a simple wrapper of the Pandas API. 
And it sounds like from your comment the lazy contract could still be honored, if they're loaded when needed?

Does that make sense? What are the arguments in the other direction?
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,124441012
https://github.com/pydata/xarray/issues/692#issuecomment-168345966,https://api.github.com/repos/pydata/xarray/issues/692,168345966,MDEyOklzc3VlQ29tbWVudDE2ODM0NTk2Ng==,1217238,2016-01-01T22:53:24Z,2016-01-01T22:53:24Z,MEMBER,"Hmm. One possible fix would be adjust `Variable.transpose` so it's a complete no-op (just returning a shallow copy) for variables with `ndim < 2`. Right now, it will convert everything into a numpy or dask array to do the transpose.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,124441012
https://github.com/pydata/xarray/issues/692#issuecomment-168138939,https://api.github.com/repos/pydata/xarray/issues/692,168138939,MDEyOklzc3VlQ29tbWVudDE2ODEzODkzOQ==,5635139,2015-12-31T07:20:11Z,2016-01-01T22:12:08Z,MEMBER,"Also peculiar - setting the `coord` to the original `coord` (saved above, but not shown here) causes the `ds.date.dtype` to report `'O'`, although not to display that in its repr, nor to cascade that for a DataArray extracted from it.

``` python
In [80]:

ds.date = date
ds, ds.date.dtype, ds['number 1'].date.dtype
Out[80]:
(<xray.Dataset>
 Dimensions:   (date: 10)
 Coordinates:
   * date      (date) int64 10957 10958 10959 10960 10961 10962 10963 10964 ...
 Data variables:
     number 1  (date) float64 0.1225 0.7202 0.5921 0.3005 0.8746 0.4186 ...
     number 2  (date) float64 0.1225 0.7202 0.5921 0.3005 0.8746 0.4186 ...
     number 3  (date) float64 0.1225 0.7202 0.5921 0.3005 0.8746 0.4186 ...
     number 4  (date) float64 0.1225 0.7202 0.5921 0.3005 0.8746 nan nan nan ...,
 dtype('O'),
 dtype('int64'))
```

Currently my workaround is `ds=ds.assign_coords(**dict(date=date.to_index()))`
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,124441012