Justus Magin

note that at the moment you still get the old character-based string dtypes by default, so you have to explicitly opt into the new string dtype (using `np.dtypes.StringDtype`, if I...

I just had a better look at this issue, and I believe it relates to us preferring explicit dtypes over implicit dtypes. What happens within `xarray` is: ```python np.result_type(np.dtype("

the failing units test is a bug in `pint`, which should be fixed and released pretty soon. For the others I'll have to investigate.

if the variant that works is implemented by `dask`, wouldn't it be fine to have `sparse` return `NotImplemented` and have it use `dask.array.Array.__rmatmul__` instead?

sorry, looks like that already happens (I think)? See https://github.com/pydata/sparse/blob/2bca00c37654f8e1116dd5c988779f68665479de/sparse/numba_backend/_coo/core.py#L958-L972 I'll have to look into why that is not triggered. Edit: maybe because the error is `TypeError` and not `NotImplementedError`?...

yeah, forwarding to `__rmatmul__` only works if we use `sparse @ dask`, whereas `xr.dot` uses something else. So we'll have to figure out how `sparse` can reject unknown array types...

I believe the issue is that `pandas.DataFrame` does not support column `attrs` (or did not? I didn't check whether that changed since then). `DataFrame`-level `attrs` should work, though.

how do we proceed, then? Merge this (after fixing the failing min-deps CI), ask if `numpy.result_type` can be changed, and remove it once we can require a version of `numpy`...

> Yes, this would be better in my opinion! There's some concerns about this in numpy/numpy#27546

@TomNicholas, should we merge this before the release?