home / github / issue_comments

Menu
  • GraphQL API
  • Search all tables

issue_comments: 422458598

This data as json

html_url issue_url id node_id user created_at updated_at author_association body reactions performed_via_github_app issue
https://github.com/pydata/xarray/pull/2330#issuecomment-422458598 https://api.github.com/repos/pydata/xarray/issues/2330 422458598 MDEyOklzc3VlQ29tbWVudDQyMjQ1ODU5OA== 1217238 2018-09-18T16:23:00Z 2018-09-18T16:23:00Z MEMBER

Sorry for taking so long here.

I'm still not entirely comfortable with this change -- it adds some additional complexity to the Dataset constructor that seems unnecessary. There's no inherit reason why calling a constructor on an object of the same type needs to work. If anything, I would like to deprecate/remove this behavior on DataArray (e.g., in favor of using a more explicit call to DataArray.copy(data=new_data)).

To answer your question though, we hit this when inheriting from a Dataset: the object is initialized with a dataset, which is super-ed up to the Dataset constructor

If I understand this correctly, you've written something like: python class MyDataset(xarray.Dataset): def __init__(self, dataset): super().__init__(dataset)

Is there any reason why you couldn't just write: python class MyDataset(xarray.Dataset): def __init__(self, dataset): super().__init__(dataset.data_vars, dataset.coords, dataset.attrs)

I think we should do something here, rather than change behavior by coincidence.

I don't think it's quite a coincidence here -- we are changing the behavior of Dataset.__iter__/Dataset.keys(), and this is a logical consequence of interpreting a Dataset as a mapping of its data variables :).

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  346294369
Powered by Datasette · Queries took 0.674ms · About: xarray-datasette