I've labelled this a question for now because NEP 50 is tricky. I placed a small reproducer with inline comments below, and I'm curious what the desired "migration" approach should be here when NEP 50/weak promotion is activated?

# on NumPy main at time of writing (03ccab7d46f8)

import numpy as np

ii = np.iinfo(int).max + 1
# this is a simplified reproducer for NEP50-activated
# https://github.com/scipy/scipy/issues/19239#issuecomment-1719764401
# which hits isnan() through assert_equal() on an int
# that is too big for int64, but does fit in uint64

res = np.isnan(ii) # False
np._set_promotion_state("weak")
res = np.isnan(ii) # OverflowError: Python int too large to convert to C long

The patch below "fixes" the problem, and I was just going to do something like that in SciPy, but I'm not sure I actually understand or agree which before/after behavior even really make sense here in the context of determining whether an integer is a NaN or not? I think I prefer the original behavior from a purist standpoint perhaps. At some potential performance cost, couldn't one short-circuit to say that no integer can be NaN at a fundamental/IEEE level?

--- a/test.py
+++ b/test.py
@@ -10,4 +10,4 @@ ii = np.iinfo(int).max + 1
 
 res = np.isnan(ii) # False
 np._set_promotion_state("weak")
-res = np.isnan(ii) # OverflowError: Python int too large to convert to C long
+res = np.isnan(np.uint64(ii))

np.isinf() also changes behavior in this way with NEP50 it seems, though I haven't thought about that one in detail.

If I had to guess what was going on, perhaps it is related to this section of the NEP: https://numpy.org/neps/nep-0050-scalar-promotion.html#proposed-weak-promotion

... Python int, float, and complex are not assigned one of the typical dtypes, such as float64 or int64. Rather, they are assigned a special abstract DType ...

At no time is the value used to decide the result of this promotion. The value is only considered when it is converted to the new dtype; this may raise an error.

I guess for the last point, if this is what is happening, the argument I have in my mind is that we shouldn't even do an initial cast prior to the internal loop or whatever, since the error message tells us the control flow already knows we have an integer, but I look forward to Sebastian telling me why I'm wrong :)