issue_comments

Table actions

6 rows where issue = 597566530 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

author_association 2

issue 1

  • examples for special methods on accessors · 6 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
877784502 https://github.com/pydata/xarray/pull/3960#issuecomment-877784502 https://api.github.com/repos/pydata/xarray/issues/3960 MDEyOklzc3VlQ29tbWVudDg3Nzc4NDUwMg== github-actions[bot] 41898282 2021-07-11T11:38:34Z 2021-07-11T11:38:34Z CONTRIBUTOR

Unit Test Results

6 files           6 suites   48m 30s :stopwatch: 16 172 tests 14 442 :heavy_check_mark: 1 730 :zzz: 0 :x: 90 228 runs  82 076 :heavy_check_mark: 8 152 :zzz: 0 :x:

Results for commit a116ee58.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   examples for special methods on accessors 597566530
628280174 https://github.com/pydata/xarray/pull/3960#issuecomment-628280174 https://api.github.com/repos/pydata/xarray/issues/3960 MDEyOklzc3VlQ29tbWVudDYyODI4MDE3NA== keewis 14808389 2020-05-13T22:32:26Z 2020-05-13T23:01:19Z MEMBER

revisiting this: does it make sense to require calling if a __call__ is defined? I.e. always require da.accessor().attribute instead of da.accessor.attribute?

This would probably need changes to the register_*_accessor decorators that adds the checking, but that way we could also make sure people don't use this to add new functions: if __call__ may only return self or a new object of the same type, abusing the accessor decorators would be a lot harder. The frequent creation of new objects would require a cheap Accessor.__init__, though.

Another way to achieve that would be to patch out __call__ and put it on a wrapper class, as mentioned above.

Does that make sense or is this too complicated?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   examples for special methods on accessors 597566530
617127917 https://github.com/pydata/xarray/pull/3960#issuecomment-617127917 https://api.github.com/repos/pydata/xarray/issues/3960 MDEyOklzc3VlQ29tbWVudDYxNzEyNzkxNw== keewis 14808389 2020-04-21T11:41:10Z 2020-04-21T11:41:10Z MEMBER

@mathause I played around with extending the example GeoAccessor to parametrize on crs but decided that the current version about reimplementing the API of weighted was easier.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   examples for special methods on accessors 597566530
617048157 https://github.com/pydata/xarray/pull/3960#issuecomment-617048157 https://api.github.com/repos/pydata/xarray/issues/3960 MDEyOklzc3VlQ29tbWVudDYxNzA0ODE1Nw== mathause 10194086 2020-04-21T08:55:11Z 2020-04-21T08:55:11Z MEMBER

+1 on not using weighted as an example - although I don't have a good idea, either... So maybe just add a note that it is included in xarray > 0.15.1?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   examples for special methods on accessors 597566530
616828508 https://github.com/pydata/xarray/pull/3960#issuecomment-616828508 https://api.github.com/repos/pydata/xarray/issues/3960 MDEyOklzc3VlQ29tbWVudDYxNjgyODUwOA== keewis 14808389 2020-04-20T21:47:45Z 2020-04-20T21:47:45Z MEMBER

I tried to polish the example (see here) and also added a note trying to explicitly discourage using this to add new methods to the main namespace.

This makes it clear, though, that the error message for the required parameter implementation could be better. For replacement, I think we could use either a new keyword-only parameter to the register_*_functions, a class decorator or some sort of mixin / base class / metaclass. The decorators would generate some sort of wrapper that enforces the __call__ while the other options would need to do some kind of magic. Considering that, I think I'd prefer using a decorator (but I'm not sure how important this use-case is).

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   examples for special methods on accessors 597566530
615484303 https://github.com/pydata/xarray/pull/3960#issuecomment-615484303 https://api.github.com/repos/pydata/xarray/issues/3960 MDEyOklzc3VlQ29tbWVudDYxNTQ4NDMwMw== jhamman 2443309 2020-04-17T22:04:12Z 2020-04-17T22:04:12Z MEMBER

Thanks @keewis!

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   examples for special methods on accessors 597566530

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