home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

3 rows where issue = 376167325 and user = 5635139 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 1

  • max-sixty · 3 ✖

issue 1

  • Check shapes of coordinates and data during DataArray construction · 3 ✖

author_association 1

  • MEMBER 3
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
851783635 https://github.com/pydata/xarray/pull/2533#issuecomment-851783635 https://api.github.com/repos/pydata/xarray/issues/2533 MDEyOklzc3VlQ29tbWVudDg1MTc4MzYzNQ== max-sixty 5635139 2021-06-01T03:47:01Z 2021-06-01T03:47:01Z MEMBER

Nice, that seems to work!

Is anyone else more familiar with whether using context in this way is reasonable?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Check shapes of coordinates and data during DataArray construction 376167325
851631521 https://github.com/pydata/xarray/pull/2533#issuecomment-851631521 https://api.github.com/repos/pydata/xarray/issues/2533 MDEyOklzc3VlQ29tbWVudDg1MTYzMTUyMQ== max-sixty 5635139 2021-05-31T18:38:43Z 2021-05-31T18:38:43Z MEMBER

Hmmmm. It's been quite some time since I've last used xarray, but I'm not sure I see an easy way to:

1. hijack np.insert (which I would guess goes directly to `DataArray.__array_wrap__ / __array_finalize__`)

2. without passing a `fastpath`-like argument to `__array_wrap__`, but

3. efficiently not checking the shape of safe operations, like `_unary_op`.

I think that's exactly correct. Without being able to tell __array_wrap__ from _unary_op that we don't need to check the sizes, they all follow the same path. Is it possible to use the context arg for this? I don't think it's sufficiently flexible from an initial glance of the docs.

Maybe this new implementation has a low enough overhead that it's worthwhile?

If we do go ahead — what about calling _check_shape_consistency from within __array_wrap__ after creating the object, instead of adding the fastpath kwarg?

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Check shapes of coordinates and data during DataArray construction 376167325
850580427 https://github.com/pydata/xarray/pull/2533#issuecomment-850580427 https://api.github.com/repos/pydata/xarray/issues/2533 MDEyOklzc3VlQ29tbWVudDg1MDU4MDQyNw== max-sixty 5635139 2021-05-28T18:00:05Z 2021-05-28T18:00:05Z MEMBER

This would still be valuable if @lilyminium (or someone else, if they're not interested) would want to finish this off.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Check shapes of coordinates and data during DataArray construction 376167325

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]);
Powered by Datasette · Queries took 160.599ms · About: xarray-datasette