issue_comments

Table actions

3 rows where issue = 587895591 and user = 5635139 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

  • max-sixty · 3 ✖

issue 1

  • Keep attrs by default? (keep_attrs) · 3 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
612501095 https://github.com/pydata/xarray/issues/3891#issuecomment-612501095 https://api.github.com/repos/pydata/xarray/issues/3891 MDEyOklzc3VlQ29tbWVudDYxMjUwMTA5NQ== max-sixty 5635139 2020-04-11T19:52:37Z 2020-04-11T19:52:37Z MEMBER

Would we want a deprecation warning on any operation with an attr?

That would be almost every operation wouldn't it?

Right, anything involving an object with attrs... hence my reluctance. Do we think it's OK to do this on a major version without a warning?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Keep attrs by default? (keep_attrs) 587895591
609830530 https://github.com/pydata/xarray/issues/3891#issuecomment-609830530 https://api.github.com/repos/pydata/xarray/issues/3891 MDEyOklzc3VlQ29tbWVudDYwOTgzMDUzMA== max-sixty 5635139 2020-04-06T14:30:26Z 2020-04-06T14:30:26Z MEMBER

Great, thanks @TomNicholas , appreciate the thoughtful reply.

One thing we could do (NB: I don't think we should do this right now, but building on the points above as ideation) is to defer to the attrs themselves. For example, in an operation dividing one dataarray by another, if they both share an attr which has a __div__ method, we call that and put the returned value on the resulting dataarray. That way, even ex-pint integration, Unit('m') / Unit('s') could evaluate to Unit('m/s'). And where units want to be dropped, they could use those methods to return None.

Re next steps on setting the default to be True, what are people's thoughts? Would we take a PR for 0.16? Would we want a deprecation warning on any operation with an attr?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Keep attrs by default? (keep_attrs) 587895591
604445960 https://github.com/pydata/xarray/issues/3891#issuecomment-604445960 https://api.github.com/repos/pydata/xarray/issues/3891 MDEyOklzc3VlQ29tbWVudDYwNDQ0NTk2MA== max-sixty 5635139 2020-03-26T13:57:47Z 2020-03-26T13:57:47Z MEMBER

Why would you want a .drop_attrs() method? .attrs.clear() will do just fine.

Yes that's fine if people are happy with .attrs.clear(). A method that returns the dataset object is useful for "fluent" method chaining.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Keep attrs by default? (keep_attrs) 587895591

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