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/issues/1613#issuecomment-422090593,https://api.github.com/repos/pydata/xarray/issues/1613,422090593,MDEyOklzc3VlQ29tbWVudDQyMjA5MDU5Mw==,98330,2018-09-17T16:53:59Z,2018-09-17T16:53:59Z,NONE,"> Requiring monotonicity lets us guarantee that the result is a NumPy view rather than possibly being a copy.

Sure, but if a users happens to have non-monotonic data it just requires her to then make that copy first anyway. Still a good thing overall for performance, but there'll be cases where it's just an extra thing to understand for the user without any performance gain.

Anyway, the non-monotonic case is less relevant, because it's harder to run into in practice. The decreasing case however is easy - there is standard geo software (looking at you ArcGIS) that can write geoTiff's with monotonic decreasing indices. That's how I ran into this. Rewriting multi-GB source data that I didn't produce is not an option, so I'm left with the manual monotonicity checks and juggling label-based slices.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,263403430
https://github.com/pydata/xarray/issues/1613#issuecomment-422083146,https://api.github.com/repos/pydata/xarray/issues/1613,422083146,MDEyOklzc3VlQ29tbWVudDQyMjA4MzE0Ng==,98330,2018-09-17T16:31:51Z,2018-09-17T16:31:51Z,NONE,"> Consider using `index.is_monotonic_ascending` and `index.is_monotonic_descending` instead of subtracting the first few values -- those are exactly the checks that pandas uses.

Thanks, that's nicer, will do. And thanks for digging up the background/rationales.

> (1)Integer slicing by position and by label with positive integers should work the same for an index with values given by `range(N)`.

This I don't think I agree with. Slicing by position and by label are semantically very different operations. 

(2) is correct, but irrelevant to label-based indexing.

(3) yes, agree that's a mistake

(4) indeed

(5) I'd say that it's in practice less important, because users normally won't do `slice(high, low)`, but for consistency I agree that there should be symmetry in behaviour. Making `slice(high, low)` return the same as `slice(low, high)` on a monotonic increasing index seems reasonable. 

Additionally: arguably monotonicity should not be required. When one uses labels, the semantics are clear without monotonicity. This doesn't have a position-based equivalent.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,263403430
https://github.com/pydata/xarray/issues/1613#issuecomment-421676579,https://api.github.com/repos/pydata/xarray/issues/1613,421676579,MDEyOklzc3VlQ29tbWVudDQyMTY3NjU3OQ==,98330,2018-09-16T02:39:50Z,2018-09-16T02:39:50Z,NONE,"In case it helps anyone else, I ended up doing:
```
    # Note that xarray is fiddly with indexing - if x or y values are ordered
    # high to low, then the slice bounds need to be reversed.  So check that
    x_ordered_low2high = data.x.values[-1] - data.x.values[0] > 0
    y_ordered_low2high = data.y.values[-1] - data.y.values[0] > 0

    if x_ordered_low2high:
        x_index = slice(lower_lon, upper_lon)
    else:
        x_index = slice(upper_lon, lower_lon)

    if y_ordered_low2high:
        y_index = slice(lower_lat, upper_lat)
    else:
        y_index = slice(upper_lat, lower_lat)

    subset = data.sel(x=x_index, y=y_index)
```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,263403430
https://github.com/pydata/xarray/issues/1613#issuecomment-421676344,https://api.github.com/repos/pydata/xarray/issues/1613,421676344,MDEyOklzc3VlQ29tbWVudDQyMTY3NjM0NA==,98330,2018-09-16T02:37:40Z,2018-09-16T02:37:40Z,NONE,"The only related issues I can find are:

- https://github.com/pandas-dev/pandas/issues/14316
- https://github.com/pandas-dev/pandas/issues/7860

They don't look identical though. Don't really have the time to dive into that further now.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,263403430
https://github.com/pydata/xarray/issues/1613#issuecomment-420296389,https://api.github.com/repos/pydata/xarray/issues/1613,420296389,MDEyOklzc3VlQ29tbWVudDQyMDI5NjM4OQ==,98330,2018-09-11T14:35:19Z,2018-09-11T14:35:19Z,NONE,"Ah okay, that makes sense. I'm sure there's a related pandas issue (or many), will try to find that later.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,263403430
https://github.com/pydata/xarray/issues/1613#issuecomment-420084948,https://api.github.com/repos/pydata/xarray/issues/1613,420084948,MDEyOklzc3VlQ29tbWVudDQyMDA4NDk0OA==,98330,2018-09-10T22:40:15Z,2018-09-10T22:41:58Z,NONE,"> The justification for this logic is that sel/loc would work like normal indexing [] on a Python list, and if you supply slice limits in the opposite order on a Python list, you get an empty result.

Given that `sel` is label/value-based, I don't see how the analogy with positional list-based indexing applies. This behavior looks like a functional bug. If you have decided to keep it as is, I'd suggest at the very least to add a warning if an empty dataset is returned because values in an attribute are ordered high...low.

EDIT: also then best to close this issue as wontfix","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,263403430