issue_comments

Table actions

2 rows where issue = 551680561 and user = 1217238 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

  • shoyer · 2 ✖

issue 1

  • Pint support for variables · 2 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
589862431 https://github.com/pydata/xarray/pull/3706#issuecomment-589862431 https://api.github.com/repos/pydata/xarray/issues/3706 MDEyOklzc3VlQ29tbWVudDU4OTg2MjQzMQ== shoyer 1217238 2020-02-21T22:23:31Z 2020-02-21T22:23:31Z MEMBER

Also, concerning the commutative operations: should we wait for hgrecco/pint#1019 and remove the flipped parameters or should we merge as is and possibly revert once pint implements a type casting hierarchy?

I don't anticipate any performance cost to this, just a small decrease in readability. So I think this is fine to merge for now with comments in the relevant sections and we can revert it later. My only suggestion is to add a note like TODO: revert after https://github.com/hgrecco/pint/issues/1019 is fixed to each comment.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Pint support for variables 551680561
583259053 https://github.com/pydata/xarray/pull/3706#issuecomment-583259053 https://api.github.com/repos/pydata/xarray/issues/3706 MDEyOklzc3VlQ29tbWVudDU4MzI1OTA1Mw== shoyer 1217238 2020-02-07T06:52:26Z 2020-02-07T06:52:26Z MEMBER

Thanks for pinging me again here (I get a lot of GitHub notifications). identical is an interesting case!

I think the current behavior (1 meter is identical to 100 centimeters) is arguably consistent with how identical currently works, which only check equality between array elements.

Right now, identical considers numbers of different data types equal, e.g., int 1 is identical to float 1.0`. I think units arguably have a similar to role to data types -- hopefully eventually libraries likepint` could be implemented via custom NumPy dtypes, rather than needing to reimplement all of NumPy.

Did this come up in the context of some other downstream use-case, or is this just something that occurred to you for the sake of consistency?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Pint support for variables 551680561

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