Slicing inconsistent for coordinates and dimensions without coordinates

[floogit]

This is a new behavior since 0.9 and has broken some of my scripts, I am not sure if this is intentional?

old, before 0.9:

ds = xr.Dataset()
ds['x'] = (('x'), np.arange(100., 200., 10.))
ds['var1'] = (('x', 'i'), np.random.rand(10, 5))

ds.sel(x=slice(110, 130), i=slice(1, 3))
<xarray.Dataset>
Dimensions:  (i: 3, x: 3)
Coordinates:
  * x        (x) float64 110.0 120.0 130.0
  * i        (i) int64 1 2 3
Data variables:
    var1     (x, i) float64 0.8894 0.01157 0.2779 0.7247 0.5809 0.3448 ...

new, since 0.9:

ds = xr.Dataset()
ds['x'] = (('x'), np.arange(100., 200., 10.))
ds['var1'] = (('x', 'i'), np.random.rand(10, 5))

ds.sel(x=slice(110, 130), i=slice(1, 3))
 <xarray.Dataset>
Dimensions:  (i: 2, x: 3)
Coordinates:
  * x        (x) float64 110.0 120.0 130.0
Dimensions without coordinates: i
Data variables:
    var1     (x, i) float64 0.9989 0.9092 0.9248 0.296 0.2209 0.5416

Maybe slicing uses the standard (excluding) python slice() for these dimensions and continues to use the (including) pandas slice for coordinates? Anyway, I find this slightly unexpected.

[benbovy]

Maybe slicing uses the standard (excluding) python slice() for these dimensions and continues to use the (including) pandas slice for coordinates?

Yes, this is what xarray does since 0.9. From the indexing section of the documentation:

Label based indexing with .sel and .loc uses standard positional, integer-based indexing as a fallback for dimensions without a coordinate label.

To fix your scripts you have to choose between set range coordinates or update the slice values.

[shoyer]

To be honest, this wasn't entirely intentional: I didn't think about the difference in slice handling conventions between labeled and unlabeled arrays when we changed this in 0.9. But at this point, I would be loathe to change it.

I suppose this is also an argument in favor of changing the slice convention we copied from pandas to exclusive rather than inclusive of upper bounds.

[stale]

In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity

If this issue remains relevant, please comment here or remove the stale label; otherwise it will be marked as closed automatically