issue_comments

Table actions

3 rows where issue = 169274464 and user = 1217238 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

These facets timed out: author_association, issue

user 1

  • shoyer · 3 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
300650769 https://github.com/pydata/xarray/issues/939#issuecomment-300650769 https://api.github.com/repos/pydata/xarray/issues/939 MDEyOklzc3VlQ29tbWVudDMwMDY1MDc2OQ== shoyer 1217238 2017-05-11T00:41:21Z 2017-05-11T00:41:21Z MEMBER

I'd much rather have pandas.read_csv the way it is right now than to have a ReadOptions object that would need to contain exactly the same documentation and be just as hard to understand as read_csv.

Certainly I agree here. The alternative would be separating out related functionality into related groups, e.g., NameOptions, ParserOptions, MissingValueOptions, DatetimeOptions, etc., basically exactly the groupings you see in the pandas docs.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Consider how to deal with the proliferation of decoder options on open_dataset 169274464
300643922 https://github.com/pydata/xarray/issues/939#issuecomment-300643922 https://api.github.com/repos/pydata/xarray/issues/939 MDEyOklzc3VlQ29tbWVudDMwMDY0MzkyMg== shoyer 1217238 2017-05-10T23:51:49Z 2017-05-10T23:52:02Z MEMBER

My concern is that open_dataset has 1 required and 12 optional arguments. This is too many to easily understand, and is generally considered poor software design. The standard solution is to group related options into objects, e.g., DecoderOptions or just Decoder (if we want to bundle related methods on the object).

pandas.read_csv is a more extreme example of the same issue.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Consider how to deal with the proliferation of decoder options on open_dataset 169274464
300623916 https://github.com/pydata/xarray/issues/939#issuecomment-300623916 https://api.github.com/repos/pydata/xarray/issues/939 MDEyOklzc3VlQ29tbWVudDMwMDYyMzkxNg== shoyer 1217238 2017-05-10T21:53:31Z 2017-05-10T21:53:31Z MEMBER

One advantage to creating classes to encapsulate these options is that it's easier to do error checking on field names and values than a dictionary. Though a dictionary is nice and lightweight.

The simplest thing to do would be to move these options out of open_dataset into a single other argument, e.g., open_dataset(filename, **kwargs) -> open_dataset(filename, decode_options=kwargs).

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Consider how to deal with the proliferation of decoder options on open_dataset 169274464

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