TYP: comparing int array to python int only gives correct type with e.g. `np.not_equal` and `.astype` cast

[brendan-m-murphy]

Describe the issue:

I have a function that compares an array whose type is revealed as ndarray[tuple[int, ...], dtype[signedinteger[_32Bit | _64Bit]]] to a python int and returns the result, which is expected to be an array of bools (return type hint is npt.NDArray[np.bool]), but mypy and pyright say the return type is Any.

For instance indexer != -1 is revealed as Any by mypy and pyright. Casting using .astype doesn't fix this. Using np.not_equal gets pyright to recognize that the result is an array, and then casting with .astype gives the correct type with pyright.

The example below shows the inferred types for the comparisons with and without casts and using != vs. np.not_equal.

Sorry if this is a duplicate!

Reproduce the code example:

import numpy as np

arr = np.arange(10)
not1 = arr != 1

reveal_type(not1) # revealed type is Any for mypy and pyright
reveal_type(not1.astype(dtype=np.bool))  # revealed type is Any for mypy and pyright

not1 = np.not_equal(arr, 1)
reveal_type(not1)  # revealed type is ndarray[tuple[int, ...], dtype[Any]] for pyright, Any for mypy
reveal_type(not1.astype(dtype=np.bool))  # revealed type is ndarray[tuple[int, ...], dtype[numpy.bool[builtins.bool]]] for pyright, Any for mypy

Error message:

mypy error:
error: Returning Any from function declared to return "ndarray[tuple[int, ...], dtype[numpy.bool[builtins.bool]]]"  [no-any-return]

Python and NumPy Versions:

python 3.10.14
numpy 2.2.4

Type-checker version and settings:

mypy 1.16.1 (with no-any-return)
pyright 1.1.403

Additional typing packages.

No response

[brendan-m-murphy]

Casting np.arange(10) to npt.NDArray[np.intp] almost gives the right result with the np.not_equal + .astype method, but is raising this issue for me: #29245 (so presumably will give the right result if I update numpy when that fix is released).

Anyway, I would expect (arr != 1).astype(np.bool) to work or np.not_equal(arr, 1) to work (or at least say the result is a boolean scalar or ndarray?).

[jorenham]

Whenever you see Any being returned from a numpy function, you can interpret that as a "TODO". According to the gradual typing guarantee this should not lead to any problems in your code:

Any allows gradually adding static types to a dynamically typed program. In a fully dynamically typed program, a static checker assigns the type Any to all expressions, and should emit no errors. Inferring static types or adding type annotations to the program (making the program more statically typed) may result in static type errors, if the program is not correct or if the static types aren’t able to fully represent the runtime types. Removing type annotations (making the program more dynamic) should not result in additional static type errors.

But I noticed several situations where doesn't always hold, though.

So apart from mypy's (IMO unrealistically strict) no-any-return error, is this causing a specific issue for you? For what it's worth, I often disable this error code in my own projects, even though I'm know to have annoyingly high standards when it comes to static typing haha. And in this case, you could argue that this error is an unhelpful one, because you are not the one responsible for causing it.
Having said that, it's not difficult to work around this error:

import numpy.typing as npt

not1: npt.NDArray[np.bool] = arr != 1

If you do something similar in your function, mypy's error should go away.

[jorenham]

Casting np.arange(10) to npt.NDArray[np.intp] almost gives the right result with the np.not_equal + .astype method, but is raising this issue for me: #29245 (so presumably will give the right result if I update numpy when that fix is released).

I don't mean to point fingers (but I will anyway 😈), but as far as I can tell that's more of a pyright issue than it is a numpy issue: microsoft/pyright#10631

[brendan-m-murphy]

@jorenham Thanks for the help! Annotating the variable works and is fairly intuitive.

So apart from mypy's (IMO unrealistically strict) no-any-return error, is this causing a specific issue for you?

No, although I need to appease mypy to pass CI (might be worth revisiting this with my team... I suppose if we have to cast results just to make mypy happy, there isn't much benefit to no-any-return. If I could get the correct result without casting, but maybe using .astype, at least then there is some assurance that the result is correct).

Thanks again!