Justus Magin

> we'll need major changes around handling array API dtype objects to do this properly. I think the change could be limited to `xarray.core.duck_array_ops.as_shared_dtype`. According to the Array API section...

The main `numpy` namespace is supposed to be Array API compatible, so it should? I don't know for certain, though.

> How do we check this? Not sure... but there are only so many builtin types that can be involved without requiring `object` dtype, so we could just enumerate all...

well, for example, what should happen for this: ```python a = xr.DataArray(np.array([1, 2, 3], dtype="int8"), dim="x") xr.where(a % 2 == 1, a, 1.2) ``` according to the algorithm above, we...

this might be cleaner: ```python def asarray(data, xp=np, dtype=None): return data if is_duck_array(data) else xp.asarray(data, dtype=dtype) def as_shared_dtype(scalars_or_arrays, xp=np): """Cast a arrays to a shared dtype using xarray's type promotion...

I see now why the dtype fallbacks for scalars is tricky... we basically need to enumerate the casting rules, and decide when to return a different dtype (like `object`). `numpy`...

here's my shot at the ~scalar dtype verification~ (the final implementation we settled on in the end is *much* better). I'm pretty sure it can be cleaned up further (and...

while 2 should eventually be resolved by an addition to the Array API, it won't help us right now to resolve the dtype casting before the release of `numpy=2.0`. As...

In the most recent commits I've added a way to check if a `dtype` is compatible with the scalars, using the second option from https://github.com/pydata/xarray/pull/8946#issuecomment-2125901039: split into weakly / strongly...

looks like the most recent commits fixed the remaining failing tests (turns out I forgot to apply our custom dtype casting rules when adjusting the dtype to fit the scalars),...