I'd draw the line at 4. nan is a ubiquitous missing-value marker for many downstream libraries (not least pandas), and that may just as well happen in an array of objects. Not 100% sure I understand "Object arrays of np.ndarray", assuming you don't mean nested arrays.

I think it would be very reasonable to have:

arr = np.array([1, '2', {3, '3'}, np.nan])
arr
# array([1, '2', {3, '3'}, nan], dtype=object)
np.isnan(arr)  # <- currently raises
# array([False, False, False,  True])

assuming you don't mean nested arrays.

No, that is what I mean

No, that is what I mean

To be fair, it wasn't clear whether the ellipses in 1. & 2. would include things such as strings, lists, maps, etc. But in any case, then I guess 3 is a good cut-off.

Would this enhancement allow

numpy.isnan(numpy.array([],dtype=object)))

to not fail?

@eric-wieser is this still relevant?

Yes, I think so. I think #6320 contains a candidate implementation.

People are bending themselves out of shape to do this. isnan and friends simply shouldn't fail on object, the error message is detrimental IMO:

TypeError: ufunc 'isnan' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

because testing for nan's (at least in principle) doesn't have anything to do with having to cast.

Even more so because adding casting="unsafe" (documented option in the signature) changes nothing.