issue_comments: 656068407

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/4208#issuecomment-656068407 https://api.github.com/repos/pydata/xarray/issues/4208 656068407 MDEyOklzc3VlQ29tbWVudDY1NjA2ODQwNw== 6213168 2020-07-09T11:18:15Z 2020-07-09T11:19:28Z MEMBER

Is it acceptable for a Pint Quantity to always have the Dask collection interface defined (i.e., be a duck Dask array), even when its magnitude (what it wraps) is not a Dask Array?

I think there are already enough headaches with __iter__ being always defined and confusing libraries such as pandas (https://github.com/hgrecco/pint/issues/1128). I don't see why pint should be explicitly aware of dask (except in unit tests)? It should only deal with generic NEP18-compatible libraries (numpy, dask, sparse, cupy, etc.).

How should xarray check for a duck Dask Array?

We should ask the dask team to formalize what defines a "dask-array-like", like they already did with dask collections, and implement their definition in xarray. I'd personally make it "whatever defines a numpy-array-like AND has a chunks method AND the chunks method returns a tuple".

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   653430454