issue_comments

Table actions

4 rows where issue = 594688816 sorted by updated_at descending

✖
✖

✎ View and edit SQL

This data as json, CSV (advanced)

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

issue 1

  • Why don't we allow indexing with keyword args via __call__? · 4 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
611332624 https://github.com/pydata/xarray/issues/3939#issuecomment-611332624 https://api.github.com/repos/pydata/xarray/issues/3939 MDEyOklzc3VlQ29tbWVudDYxMTMzMjYyNA== TomNicholas 35968931 2020-04-09T05:14:46Z 2020-04-09T05:14:46Z MEMBER

There may also be functions that check whether arguments are callable (where / assign) that would break.

I didn't think of this one.

These are all good reasons - I was just kind of idly wondering :man_shrugging:

Will close now.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Why don't we allow indexing with keyword args via __call__? 594688816
611322614 https://github.com/pydata/xarray/issues/3939#issuecomment-611322614 https://api.github.com/repos/pydata/xarray/issues/3939 MDEyOklzc3VlQ29tbWVudDYxMTMyMjYxNA== shoyer 1217238 2020-04-09T04:33:41Z 2020-04-09T04:33:41Z MEMBER

I'm pretty happy with the .sel() API. One major advantage over using __call__ is that you can Google search for something like "xarray sel" and get sensible results.

The main downside is that you can't use it for assignment, but that wouldn't be solved by overriding __call__ either.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Why don't we allow indexing with keyword args via __call__? 594688816
609556676 https://github.com/pydata/xarray/issues/3939#issuecomment-609556676 https://api.github.com/repos/pydata/xarray/issues/3939 MDEyOklzc3VlQ29tbWVudDYwOTU1NjY3Ng== max-sixty 5635139 2020-04-06T04:20:23Z 2020-04-06T04:31:05Z MEMBER

Thanks for the suggestion @TomNicholas

I’d be -0.5 on this; it’s unpythonic given it’s not a call, and I do think it’s generally worth being consistent with the wider language.

There may also be functions that check whether arguments are callable (where / assign) that would break.

I also think our current solution of .sel is pretty good. If there’s demand for .loc(x=2), that would less intrusive than on the main object. 

{
    "total_count": 3,
    "+1": 3,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Why don't we allow indexing with keyword args via __call__? 594688816
609558708 https://github.com/pydata/xarray/issues/3939#issuecomment-609558708 https://api.github.com/repos/pydata/xarray/issues/3939 MDEyOklzc3VlQ29tbWVudDYwOTU1ODcwOA== fujiisoup 6815844 2020-04-06T04:29:19Z 2020-04-06T04:29:19Z MEMBER

Agreed with @max-sixty. I also like sel and isel as they are clearly distinguishable. It is not clear to me if parenthesis corresponds to sel or isel.

For me, the largest drawback of sel and isel is the fact that autocompleters can not suggest the dimension names (it is another issue though)

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Why don't we allow indexing with keyword args via __call__? 594688816

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]);