issue_comments

Table actions

4 rows where author_association = "NONE", issue = 263403430 and user = 2086210 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 1

  • brianmapes · 4 ✖

issue 1

  • Should sel with slice objects care about underlying coordinate order? · 4 ✖

author_association 1

  • NONE · 4 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1062281975 https://github.com/pydata/xarray/issues/1613#issuecomment-1062281975 https://api.github.com/repos/pydata/xarray/issues/1613 IC_kwDOAMm_X84_USL3 brianmapes 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
}
   Should sel with slice objects care about underlying coordinate order? 263403430
1062142845 https://github.com/pydata/xarray/issues/1613#issuecomment-1062142845 https://api.github.com/repos/pydata/xarray/issues/1613 IC_kwDOAMm_X84_TwN9 brianmapes 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
}
   Should sel with slice objects care about underlying coordinate order? 263403430
1058446923 https://github.com/pydata/xarray/issues/1613#issuecomment-1058446923 https://api.github.com/repos/pydata/xarray/issues/1613 IC_kwDOAMm_X84_Fp5L brianmapes 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
}
   Should sel with slice objects care about underlying coordinate order? 263403430
1058341139 https://github.com/pydata/xarray/issues/1613#issuecomment-1058341139 https://api.github.com/repos/pydata/xarray/issues/1613 IC_kwDOAMm_X84_FQET brianmapes 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
}
   Should sel with slice objects care about underlying coordinate order? 263403430

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);