Fix: coerce unknown types to O dtype

[brynpickering]

Added a check for Python objects that neither have numpy dtype dtype attributes nor are one of the builtin types so that type promotion succeeds and defaults to object dtype.

This deals with cases where user-defined instances are in the array which would otherwise trip up numpy.result_type.

I did think about placing this in xarray.core.dtypes.preprocess_types but chose to place it closest to where it causes issues (namely, on calling xp.result_type).

• Closes Cannot apply sum to custom object arrays with min_count=1 if n_dims <= sum_dims #9755
• Tests added
• User visible changes (including notable bug fixes) are documented in whats-new.rst
• New functions/methods are listed in api.rst

[max-sixty]

do you think we could add a quick comment in the code describing what it's doing, for the less informed of us?

(does anyone know this better?)

[brynpickering]

Sure, done.

Another options for this would be to check all the args passed to the compat.array_api_compat.result_type method and if any of them are not a numpy-compatible object or a builtin type then just return np.object_ directly. Passing the args to np.result_type is unnecessary as any object dtype in the list will automatically lead to an object dtype being returned (as it's the lowest common denominator).

[brynpickering]

@keewis is there any timeline for this to be reviewed? We're currently stuck with xarray v2024.2.0 as a dependency until this is resolved which is starting to cause issues when used in some working environments.

[keewis]

sorry, this had completely dropped off my radar.

If this is about scalars, note that you can already wrap your custom object in a 0D array of object dtype to work around this (so you don't have to wait on us)

@shoyer, do you have an opinion on this?

[shoyer]

Let's get this in after applying @keewis's suggested clean-up?

[brynpickering]

@keewis @shoyer thanks both. I've committed the suggestion as-is.

[brynpickering]

Aha @keewis I see we're working on fixing this simultaneously!

With 788eedb the MWE in the originating issue now passes all checks

[keewis]

yeah, I thought I'd help you fix the untested parts of what I suggested