issue_comments

Yes, @TomNicholas. My PR got merged but I forgot to close the issue -- closing it now. Thanks for checking.

@shoyer, I spent sometime looking into it and it looks like the test fails for the shallow copy, and apparently only on Windows for some reason. In Windows coords seem to be immutable unless it's one dataarray deep copied from another (which is why only the deep=False test fails). So I decided to just mark the tests as xfail for now (but I'd be happy to create an issue and look into it more in the future).

I'll open a new PR marking the tests with xfail shortly.

Sure. I'm looking into it now.

Sorry about that.

Yep, the tests are back now.

@pletchm thanks for the PR!

I think the test failuers are dependencies rather than your changes! I kicked off a build of master here: https://travis-ci.org/pydata/xarray/builds/524754660 to confirm - if it's the same failures then we'll know it's not this code

Thanks for looking into this, @max-sixty! It looks like the errors are the same, so the problem is dependencies, right? How do we go about fixing that?

Tests and documentation forthcoming. I had already opened a PR, but was perplexed when the build and tests weren't passing -- suspected it was related to my commits.

I'm perplexed by why the build and tests are failing on this. I'm going to try 3 things: 1) Make a new branch from master and PR (making sure my fork master is synced up with the upstream master) to see if the tests/build pass without any additional commits 2) Commit my non-test changes and see if the build/tests pass 3) Commit my tests and see if the build/tests pass Then I'll rebase my 2 commits into 1 commit.

Another solution could be adding support for da.sel(dim1='a', squeeze=False) to avoid losing the dim1 dimension/coordinate in the first place

Or equivalently, you could just do da.sel(dim1=['a'])

I'd like to take a shot fixing this bug unless someone else already is working on it. Would that be alright?

@shoyer, dim_kwargs is no longer allowed to be used for python 3.5. Does anything else need to change in this PR?

Hi @shoyer and @fujiisoup, I believe I've made all of the updates that you suggested in your comments. How is the PR looking now? Thank you!

Oh I see what you're saying. Yeah, that makes sense.

To get the equivalent of da.expand_dims(a=[9, 10, 11]), you'd do ```

new = da.expand_dims(a=3) new <xarray.DataArray (a: 3, b: 5, c: 3)> ... Coordinates: * b (b) int64 0 1 2 3 4 * c (c) int64 0 1 2 Dimensions without coordinates: a new["a"] = [9, 10, 11] ```

Those would be equivalent, I think, assuming they're both manipulating the same da object (I meant for them to be separate calls not sequential, but even if they were sequential, expand_dims doesn't and wouldn't alter da, but instead return a new xarray object). I edited my above post to clarify what da is.

Hi, Thanks for replying. I see what you mean about the 2 separate features.

Would it be alright if I opened a PR sometime soon that upgraded expand_dims to support the inserting/broadcasting dimensions with size > 1 (the first feature)?

I would use your suggested API, i.e. not requiring explicit coordinate names -- that makes sense. However, it feels like the dimension kwargs (i.e. the new dimension/dimensions), should be allowed to be given implicit or explicit coordinates, in case the user doesn't want 0-based integer coordinates for the new dimension. For example, da.expand_dims(a=3) is equivalent to da.expand_dims(a=[0, 1, 2]) but this will also work da.expand_dims(a=['w', 'x', 'y', 'z']) where da is ```

coords = {"b": range(5), "c": range(3)} da = xr.DataArray(np.ones([5, 3]), coords=coords, dims=list(coords.keys())) da <xarray.DataArray (b: 5, c: 3)> array([[1., 1., 1.], [1., 1., 1.], [1., 1., 1.], [1., 1., 1.], [1., 1., 1.]]) Coordinates: * b (b) int64 0 1 2 3 4 * c (c) int64 0 1 2 ```` Does that make sense?

Thank you! Martin