issue_comments

Table actions

2 rows where issue = 894125618 and user = 9010180 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

  • pont-us · 2 ✖

issue 1

  • xarray 0.18.0 raises ValueError, not FileNotFoundError, when opening a non-existent file · 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
843895606 https://github.com/pydata/xarray/issues/5329#issuecomment-843895606 https://api.github.com/repos/pydata/xarray/issues/5329 MDEyOklzc3VlQ29tbWVudDg0Mzg5NTYwNg== pont-us 9010180 2021-05-19T08:54:57Z 2021-05-19T08:54:57Z NONE

I think it is OK to add a dedicated xarray.EngineGuessingError, but I'd not try anything more complex and in general invite users to pass engine explicitly.

I'm reluctantly inclined to agree. (But "reluctantly" only because this means that we may have a lot of xcube code to check and update now.) If the engine is explicitly specified, the question of which exceptions to expect becomes a lot easier to handle, since it's now just between the caller and the engine.

Probably the open_dataset documentation should actively discourage reliance on engine guessing for anything but interactive use, and point out that callers need to check the documentation for the selected engine to determine which exceptions (other than EngineGuessingError) might be thrown.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   xarray 0.18.0 raises ValueError, not FileNotFoundError, when opening a non-existent file 894125618
843138842 https://github.com/pydata/xarray/issues/5329#issuecomment-843138842 https://api.github.com/repos/pydata/xarray/issues/5329 MDEyOklzc3VlQ29tbWVudDg0MzEzODg0Mg== pont-us 9010180 2021-05-18T12:43:55Z 2021-05-18T13:40:41Z NONE

@aurghs Point taken, but in that case the xarray.open_dataset documentation probably needs updating: currently it says ‘Strings and Path objects are interpreted as a path to a netCDF file or an OpenDAP URL and opened with python-netCDF4, unless the filename ends with .gz…’. In particular I find the behaviour with Path confusing: this type is unambiguously a filesystem path, but still results in a ValueError rather than FileNotFoundError. And in Python 3, str and bytes are distinct (though I suppose a str might still be a URL rather than a file).

In principle, though, I'd be OK with any selection of potential exceptions, as long as they're documented. The current practical problem for us (the xcube developers) is that the behaviour change from 0.17 to 0.18 means that we now have to audit our existing codebases for potential uncaught ValueErrors.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   xarray 0.18.0 raises ValueError, not FileNotFoundError, when opening a non-existent file 894125618

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