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-1062281975,https://api.github.com/repos/pydata/xarray/issues/1613,1062281975,IC_kwDOAMm_X84_USL3,2086210,2022-03-08T22:26:07Z,2022-03-08T22:26:07Z,NONE,"Agreed, new rather than redefine existing meanings. 
Who has the chops and the cred to implement it? Not quite me... ","{""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-1062142845,https://api.github.com/repos/pydata/xarray/issues/1613,1062142845,IC_kwDOAMm_X84_TwN9,2086210,2022-03-08T19:49:33Z,2022-03-08T19:49:33Z,NONE,"How about an informative warning when returning an empty set, as a minimal change? What's the path to an action item here? ","{""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-1058446923,https://api.github.com/repos/pydata/xarray/issues/1613,1058446923,IC_kwDOAMm_X84_Fp5L,2086210,2022-03-03T20:19:56Z,2022-03-03T20:19:56Z,NONE,"@shoyer, `selection over non-monotonic indexes, merely based on matching bounds` is a case I never considered... probably a rare one, which I for one would happily sacrifice. 

New syntax like your first suggestion, `.Between` instead of `.slice` if I understand correctly, could be appealing too:  The word 'slice' has never seemed terribly intuitive to this user, and 'between' is high in an alphabetical list of tips/suggestions a good IDE might bring up with the tab key or whatever. ","{""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-1058341139,https://api.github.com/repos/pydata/xarray/issues/1613,1058341139,IC_kwDOAMm_X84_FQET,2086210,2022-03-03T18:13:31Z,2022-03-03T20:03:15Z,NONE,"How about: add one code line at the top of `slice` that properly orders the exactly two arguments (in other words, reverses the order if necessary)? I haven't studied the code at all, this may be naive. This may the same as 1. above (make `sel` ignore order). Ideally the default would be silently improved, rather than creating something optional that users would have to make a new habit of, like an additional kwarg or new syntax. ","{""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-678676112,https://api.github.com/repos/pydata/xarray/issues/1613,678676112,MDEyOklzc3VlQ29tbWVudDY3ODY3NjExMg==,26384082,2020-08-22T18:34:59Z,2020-08-22T18:34:59Z,NONE,"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
","{""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-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