issue_comments

The only concern I have for the repr changes is using the symbol * for missing coordinates. To me * really means that it is an index. Maybe just remove it? e.g.,

Coordinates: * y (y) |S1 'a' 'b' 'c' * x (x) int64 1 2 3 4 5 z (z) -

or use another symbol like o that means 'no index'?

Coordinates: * y (y) |S1 'a' 'b' 'c' * x (x) int64 1 2 3 4 5 o z (z) -

and/or even remove the coordinate name (because there is no coordinate)

Coordinates: * y (y) |S1 'a' 'b' 'c' * x (x) int64 1 2 3 4 5 o (z) -

Coordinates: * y (y) |S1 'a' 'b' 'c' * x (x) int64 1 2 3 4 5 (z) -

I also understand (1), but renaming Coordinates to Dimensions would be a bit odd too, especially in case multiple coordinates for a given dimension or multi-dimensional coordinates.

Another suggestion may be to "highlight" in the top list the dimensions which have an index, using the same symbol than in the coordinate list:

<xarray.DataArray (*x: 5, *y: 3, z: 7)> dask.array<xarray-..., shape=(5, 3, 7), dtype=float64, chunksize=(5, 3, 7)> Coordinates: * y (y) |S1 'a' 'b' 'c' * x (x) int64 1 2 3 4 5

+1 for the align error.

Yes. But, in that case you need a way to do the "fill with NAN" option without having to jump through too many hoops. How would you do that?

Using .set_index() (#1028) before .reindex_like() seems fine in that case. It's not much longer and it's more explicit.

Oops, I missed .diff() that already solves my given example. Anyway, I can vaguely see other cases (e.g., map algebra) where we want to compare or combine image or raster subsets (i.e., after some indexing) that have the same shape but that don't overlap or that come from sources with different sizes. That can be an issue if we create dummy coordinates when indexing, though reset_index() would help and would certainly be enough here.

Should we create dummy/virtual coordinates like range(n) on demand when indexing a dimension without labels?

I think about some possible use cases where this behavior - if I understand it well - may not be desired. For example, if we want to compute partial derivatives by finite difference, using xarray would not give the expected result (as numpy does):

``` python

z = np.random.rand(5, 5) dz_dx_numpy = z[1:, :] - z[:-1, :] # forward difference dz_dx_numpy array([[-0.16122906, -0.73841927, 0.11565084, 0.94529388, 0.04245993], [ 0.21066572, 0.11964058, -0.11203992, -0.52073269, -0.50827324], [-0.42100012, 0.39873985, 0.07957889, -0.02071456, 0.59944732], [-0.53819024, -0.29738881, 0.35238292, 0.01903809, 0.15671588]])

da = xr.DataArray(z, dims=('x', 'y'), name='z') dz_dx_xarray = da[1:, :] - da[:-1, :] # forward difference dz_dx_xarray <xarray.DataArray 'z' (x: 3, y: 5)> array([[ 0., 0., 0., 0., 0.], [ 0., 0., 0., 0., 0.], [ 0., 0., 0., 0., 0.]]) Coordinates: * x (x) int64 1 2 3 ```

However, I guess that this specific kind of problem should rather be addressed using the upcoming logic for applying vectorized functions to xarray objects (#964).

e.g., array.coords['x'] would return a DataArray with values range(n) (importantly, this would not change the original array).

That sounds a bit weird to me (I'm not sure to understand, actually). What are the reasons/benefits of returning a DataArray instead of raising a KeyError?