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/4221#issuecomment-660157829,https://api.github.com/repos/pydata/xarray/issues/4221,660157829,MDEyOklzc3VlQ29tbWVudDY2MDE1NzgyOQ==,3460034,2020-07-17T15:04:50Z,2020-07-17T15:04:50Z,CONTRIBUTOR,"@rpmanser For what it's worth, I'd think doing tests like `test_dask.py` but with a post-https://github.com/hgrecco/pint/pull/1129 Pint Quantity or suitably mocked wrapper class between xarray and Dask would be best. But, I think this is more of a maintainer-level question.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,656163384
https://github.com/pydata/xarray/pull/4221#issuecomment-658140708,https://api.github.com/repos/pydata/xarray/issues/4221,658140708,MDEyOklzc3VlQ29tbWVudDY1ODE0MDcwOA==,3460034,2020-07-14T12:03:05Z,2020-07-14T12:03:19Z,CONTRIBUTOR,"> Revisiting it I now realize that `is_array_like` is actually not a good name for that function: officially, ""array_like"" means that it can be casted using `np.asarray`. Maybe we should rename that to `is_duck_array`? But then we'd also need to check for `__array_ufunc__` and `__array_function__` because we also need those to properly wrap duck arrays.

As long as that doesn't break any of the current uses, I think that would be the best way forwards. This would require xarray to be on NumPy 1.16+ (in order to ensure `hasattr(np.ndarray, ""__array_function__"")`, but that's only 9 days away by NEP 29, so hopefully that isn't too much of an issue. Then, most of the checks for ""can this be wrapped by xarray"" should be able to become something like

```python
is_duck_array(x) and not isinstance(x, (DataArray, Variable))
```
with `is_duck_dask_array` only being needed for checking Dask Array-like support. 

Although, while we're at it, do we also need more careful handling of upcast types? I'm not sure if there even are any out there right now (not sure if a HoloViews Dataset counts here), but that doesn't necessarily mean there never will be any.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,656163384
https://github.com/pydata/xarray/pull/4221#issuecomment-657895835,https://api.github.com/repos/pydata/xarray/issues/4221,657895835,MDEyOklzc3VlQ29tbWVudDY1Nzg5NTgzNQ==,3460034,2020-07-14T00:22:09Z,2020-07-14T00:22:09Z,CONTRIBUTOR,"Also, a broader discussion that's I've seen hinted to in the past, but is brought to the forefront by this PR: how should xarray be checking for general duck array types it can wrap?

Right now, it looks like there is a mix of 

```python
is_array_like(data)
```
and
```python
hasattr(data, ""__array_function__"") or isinstance(data, dask_array_type)
```

and it would be nice to bring consistency. However, both these checks seem like they'd let too many types through. For example, `is_array_like` as currently implemented would still let through too much, such as `MemoryCachedArray` and xarray Variables/DataArrays, and `__array_function__` doesn't truly indicate a NumPy duck array on its own (and it really only works to only capture downcast types right now since xarray does not yet implement `__array_function__` itself, #3917).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,656163384