home / github

Menu
  • GraphQL API
  • Search all tables

issue_comments

Table actions
  • GraphQL API for issue_comments

8 rows where issue = 344631360 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 3

  • ocefpaf 3
  • shoyer 3
  • DocOtak 2

author_association 2

  • CONTRIBUTOR 5
  • MEMBER 3

issue 1

  • Behavior of filter_by_attrs() does not match netCDF4.Dataset.get_variables_by_attributes · 8 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
408274199 https://github.com/pydata/xarray/issues/2315#issuecomment-408274199 https://api.github.com/repos/pydata/xarray/issues/2315 MDEyOklzc3VlQ29tbWVudDQwODI3NDE5OQ== shoyer 1217238 2018-07-27T00:22:13Z 2018-07-27T00:22:13Z MEMBER

I agree, I think we can change the behavior here to something more rationale. Arguably the existing behavior is a bug.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Behavior of filter_by_attrs() does not match netCDF4.Dataset.get_variables_by_attributes 344631360
408268331 https://github.com/pydata/xarray/issues/2315#issuecomment-408268331 https://api.github.com/repos/pydata/xarray/issues/2315 MDEyOklzc3VlQ29tbWVudDQwODI2ODMzMQ== ocefpaf 950575 2018-07-26T23:44:49Z 2018-07-26T23:44:49Z CONTRIBUTOR

I can work on a PR tomorrow. Does the benefit of having the same behavior as the netCDF4 library warrant a potentially breaking change for existing code which relies on the current behavior of filter_by_attrs()?

IMO, yes.

This might need adding a new method with the same behavior as netCDF4 and keeping the existing one as is (with appropriate documentation updates).

That is up to xarray devs but I personally don't think it is necessary.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Behavior of filter_by_attrs() does not match netCDF4.Dataset.get_variables_by_attributes 344631360
408263759 https://github.com/pydata/xarray/issues/2315#issuecomment-408263759 https://api.github.com/repos/pydata/xarray/issues/2315 MDEyOklzc3VlQ29tbWVudDQwODI2Mzc1OQ== DocOtak 868027 2018-07-26T23:17:26Z 2018-07-26T23:17:26Z CONTRIBUTOR

I can work on a PR tomorrow. Does the benefit of having the same behavior as the netCDF4 library warrant a potentially breaking change for existing code which relies on the current behavior of filter_by_attrs()? This might need adding a new method with the same behavior as netCDF4 and keeping the existing one as is (with appropriate documentation updates).

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Behavior of filter_by_attrs() does not match netCDF4.Dataset.get_variables_by_attributes 344631360
408262225 https://github.com/pydata/xarray/issues/2315#issuecomment-408262225 https://api.github.com/repos/pydata/xarray/issues/2315 MDEyOklzc3VlQ29tbWVudDQwODI2MjIyNQ== ocefpaf 950575 2018-07-26T23:09:06Z 2018-07-26T23:09:06Z CONTRIBUTOR

Got it. I cannot dig into this at the moment but having both implementations working in a consistent way would be nice. Do you want to send a PR?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Behavior of filter_by_attrs() does not match netCDF4.Dataset.get_variables_by_attributes 344631360
408260961 https://github.com/pydata/xarray/issues/2315#issuecomment-408260961 https://api.github.com/repos/pydata/xarray/issues/2315 MDEyOklzc3VlQ29tbWVudDQwODI2MDk2MQ== DocOtak 868027 2018-07-26T23:01:44Z 2018-07-26T23:01:44Z CONTRIBUTOR

I'm fairly certain that the netCDF4.Dataset.get_variables_by_attributes behaves as a logical AND.

Here is the currently implementation body from https://github.com/Unidata/netcdf4-python/blob/master/netCDF4/_netCDF4.pyx#L2868 ```python vs = []

has_value_flag = False

this is a hack to make inheritance work in MFDataset

(which stores variables in _vars)

_vars = self.variables if _vars is None: _vars = self._vars for vname in _vars: var = _vars[vname] for k, v in kwargs.items(): if callable(v): has_value_flag = v(getattr(var, k, None)) if has_value_flag is False: break elif hasattr(var, k) and getattr(var, k) == v: has_value_flag = True else: has_value_flag = False break

if has_value_flag is True: vs.append(_vars[vname])

return vs ```

The difference appears to be in the presence of that has_value_flag and the breaks in the innermost loop. I must admit I had a little trouble following the above code, but it seems that when any of they key=value tests fails, it will stop checking the current variable (DataArray in the xarray context) and check the next variable.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Behavior of filter_by_attrs() does not match netCDF4.Dataset.get_variables_by_attributes 344631360
408255439 https://github.com/pydata/xarray/issues/2315#issuecomment-408255439 https://api.github.com/repos/pydata/xarray/issues/2315 MDEyOklzc3VlQ29tbWVudDQwODI1NTQzOQ== ocefpaf 950575 2018-07-26T22:32:29Z 2018-07-26T22:32:29Z CONTRIBUTOR

it appears that this scenario was not directly contemplated.

Correct. I did not foresee that use case. Are you sure that netCDF4.Dataset.get_variables_by_attributes behaves as a logical AND? The code is virtually a copy-n-paste from there.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Behavior of filter_by_attrs() does not match netCDF4.Dataset.get_variables_by_attributes 344631360
408254512 https://github.com/pydata/xarray/issues/2315#issuecomment-408254512 https://api.github.com/repos/pydata/xarray/issues/2315 MDEyOklzc3VlQ29tbWVudDQwODI1NDUxMg== shoyer 1217238 2018-07-26T22:27:59Z 2018-07-26T22:27:59Z MEMBER

Looking at the original PR (https://github.com/pydata/xarray/pull/844), it appears that this scenario was not directly contemplated. I don't see any test coverage.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Behavior of filter_by_attrs() does not match netCDF4.Dataset.get_variables_by_attributes 344631360
408246470 https://github.com/pydata/xarray/issues/2315#issuecomment-408246470 https://api.github.com/repos/pydata/xarray/issues/2315 MDEyOklzc3VlQ29tbWVudDQwODI0NjQ3MA== shoyer 1217238 2018-07-26T21:52:14Z 2018-07-26T21:52:14Z MEMBER

cc @ocefpaf, who contributed this method originally

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Behavior of filter_by_attrs() does not match netCDF4.Dataset.get_variables_by_attributes 344631360

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]);
Powered by Datasette · Queries took 12.845ms · About: xarray-datasette