More Robust Implementation of slice

[jdossgollin]

Currently, only one of the two operations: ds.sel(lon = slice(X0, X1)) and ds.sel(lon = slice(X1, X0)) works; the other will give a data array (or dataset) with zero values. This can be a difficulty when working with different data sets which have different indexing methods.

It would be great to have slice implemented, at least in the context of sel, to check whether the index of ds is increasing or decreasing, and then take the min and max of X0 and X1 accordingly.

[fmaussion]

While it seems a good idea at first (I've fallen into this as well), I'm not sure this would be a good idea. Look at pandas for example:

In [1]: import pandas as pd

In [2]: ts = pd.Series([1, 2, 3, 4,])

In [3]: ts[1:3]
Out[3]: 
1    2
2    3
dtype: int64

In [4]: ts[3:1]
Out[4]: Series([], dtype: int64)

I don't think one would like the last statement to return something else than an empty series.

[jdossgollin]

Definitely a fair point, but would it be possible to add an argument to either slice or sel (probably slice) which defaults to False? For example, ds.sel(lon = slice(X0, X1, both_ways = True) would implement this behavior, but both_ways defaults to False.

[shoyer]

I agree that this is somewhat surprising, but as @fmaussion points out this slicing behavior is consistent with pandas (and Python more generally, nothing that range(5)[3:1] is empty).

slice is a Python built-in, so we can't adjust it. What we could potentially do is add a new keyboard argument to .sel() (or add a new indexing method entirely).

[jdossgollin]

Definitely want to leave it up to you guys but agree that putting it in slice probably doesn't make sense. Adding something to .sel() would be a cool feature in the spirit of projects like Aospy, which try to minimize the amount code re-writing necessary for carrying out simple analysis on different datasets which are often organized in subtly different ways. Of course, it's pretty easy for users to implement this ourselves if we really need. Thanks for considering!

[dcherian]

Closing in favour of #1613 which has more discussion.