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/pull/2972#issuecomment-493798254,https://api.github.com/repos/pydata/xarray/issues/2972,493798254,MDEyOklzc3VlQ29tbWVudDQ5Mzc5ODI1NA==,13662783,2019-05-19T22:41:49Z,2019-05-19T22:46:06Z,CONTRIBUTOR,"I'm definitely not convinced it's a great idea either; a pull request is hopefully the best way to get some discussion going! Putting it in the `_get_joiner` is definitely the sensible choice, and the last suggestion is definitely more clear to me.

I've had a bit more thought and maybe it's useful to consider what xarray's philosophy about these things is. I think flexibility is a primary concern and generally, things \*just work\*. The reason I'm running into issues here is because I'm writing some code which operates on DataArrays, which isn't nearly as robust or flexible, and **doesn't** just work.

The answer in this case might be that I should be using xarray's powerful alignment machinery to do the work for me, rather than to assume/demand certain features of the data. Of course, that requires some digging into how xarray does alignment. But I'd end up with a more flexible tool in the end.

Perhaps that should be the general rule: if you're extending xarray, like xarray, *don't* rely too much about your coordinates staying the way they are. Maybe such a description could belong in the [xarray Internals page](http://xarray.pydata.org/en/stable/internals.html) just to make it explicit.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,445745470