issue_comments

Table actions

4 rows where author_association = "CONTRIBUTOR", issue = 755607271 and user = 32801740 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

  • rhkleijn · 4 ✖

issue 1

  • astype method lost its order parameter · 4 ✖

author_association 1

  • CONTRIBUTOR · 4 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
743129921 https://github.com/pydata/xarray/issues/4644#issuecomment-743129921 https://api.github.com/repos/pydata/xarray/issues/4644 MDEyOklzc3VlQ29tbWVudDc0MzEyOTkyMQ== rhkleijn 32801740 2020-12-11T11:05:04Z 2020-12-11T11:08:57Z CONTRIBUTOR

Working on a unit test for the subok argument I found no way for creating a DataArray backed by a subclass of np.ndarray (even with NEP 18 enabled).

The DataArray constructor calls xr.core.variable.as_compatible_data. This function:

  • converts np.ma instances to np.ndarray with fill values applied.
  • the NEP 18 specific branch which would keep the supplied data argument (and its type) is not reachable for (subclasses of) np.ndarray
  • it converts these subclasses to np.ndarray.

Is this behaviour intentional?

What to do with astype? If the behaviour is not intentional we could add the subok unit test but marked as xfail until that is fixed. If it is intentional we could omit the subok argument here.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   astype method lost its order parameter 755607271
743129841 https://github.com/pydata/xarray/issues/4644#issuecomment-743129841 https://api.github.com/repos/pydata/xarray/issues/4644 MDEyOklzc3VlQ29tbWVudDc0MzEyOTg0MQ== rhkleijn 32801740 2020-12-11T11:04:53Z 2020-12-11T11:04:53Z CONTRIBUTOR

I will also include xarray's recently added keep_attrs argument. Since the signature has been in flux both in version 0.16.1 and now again I intend to make all arguments following dtype keyword-only in order to avoid introducing unnoticed bugs when user code calls it with positional arguments.

def astype(self, dtype, *, order=None, casting=None, subok=None, copy=None, keep_attrs=True)

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   astype method lost its order parameter 755607271
738946975 https://github.com/pydata/xarray/issues/4644#issuecomment-738946975 https://api.github.com/repos/pydata/xarray/issues/4644 MDEyOklzc3VlQ29tbWVudDczODk0Njk3NQ== rhkleijn 32801740 2020-12-04T18:32:46Z 2020-12-04T18:32:46Z CONTRIBUTOR

That is a nicer solution. Never contributed a PR before, but I'll try to work on this next week. It looks like a good first issue.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   astype method lost its order parameter 755607271
737899772 https://github.com/pydata/xarray/issues/4644#issuecomment-737899772 https://api.github.com/repos/pydata/xarray/issues/4644 MDEyOklzc3VlQ29tbWVudDczNzg5OTc3Mg== rhkleijn 32801740 2020-12-03T12:03:42Z 2020-12-03T12:03:42Z CONTRIBUTOR

IIUC before PR #4314 numpy.ndarray.astype was used and the order parameter was just part of that. Looking through PR #4314 it seems that the 'casting' parameter required some special casing in duck_array_ops.py since not all duck arrays did support it (in particular sparse arrays only gained it very recently). In the current case the order parameter is not supported at all for sparse arrays.

I am thinking it might not even be worthwhile to add support for an order parameter similar to the numpy.ndarray.astype method:

  • It would add more special casing logic to xarray.
  • To the user it would result in either noisy warnings or silently dropping parameters.
  • To me, the kind of contiguousness seems more like an implementation detail of the array type of the underlying data than as a property of the encapsulating xarray object.
  • For my use case (with numpy arrays as the underlying data) I can quite easily work around this issue by using something like da.copy(data=np.asfortranarray(da.data)) for the example above (or np.ascontiguousarray for C contiguousness).

Another option might be to allow arbitrary **kwargs which will be passed through as-is to the astype method of the underlying array and making it the responsibility of the user to only supply parameters which make sense for that particular array type.

What are your thoughts? Does xarray have some kind of policy for supporting parameters which might not make sense for all types of duck arrays?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   astype method lost its order parameter 755607271

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