home / github / issue_comments

Menu
  • Search all tables
  • GraphQL API

issue_comments: 660201690

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/issues/3245#issuecomment-660201690 https://api.github.com/repos/pydata/xarray/issues/3245 660201690 MDEyOklzc3VlQ29tbWVudDY2MDIwMTY5MA== 1610850 2020-07-17T16:22:06Z 2020-07-17T16:22:06Z CONTRIBUTOR

@dcherian pointed me over here after I raised #4234.

I like as_sparse and as_dense, because it makes clear that the objects are still xarray objects. I agree with @fujiisoup that to_sparse``todense could be confused to return sparse arrays directly.

I very much agree with this reasoning. to_ sounds like it is converting the whole thing to another type. as_ sounds like it is remaining the same but something about it (the underlying array type) is changing.

Basically, we should leave the decision about whether automatic coercion is safe up to the authors of duck array libraries.

I also agree with this reasoning. In cupy many things will break because np.asarray(cupy_array) will raise. So something like cupy_da.plot() will raise. But the exception will be ValueError: object __array__ method not producing an array which isn't particularly user friendly in this case.

For cupy I do think that automatic coercion to numpy for .values and plot() is a reasonable thing to do. But I understand that may not be true for all duck type arrays.

One suggestion is to add an accessor to make things explicit. So it would become cupy_da.cupy.plot(). Where this plot function coerces to numpy and then calls the upstream plot method. However this feels less satisfying.

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