You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
BUG: Sum of ndarray subclassess incorrectly typed as np.ndarray #20072
In my code I'm using a slightly customized numpy subclass. When I sum two numpy arrays viewed as this class, the result has a different type. I'd expect the sum to be of the same type as the two addends.
test-mypy-numpy.py:12: note: Revealed type is "test-mypy-numpy.State"
test-mypy-numpy.py:13: note: Revealed type is "test-mypy-numpy.State"
test-mypy-numpy.py:14: note: Revealed type is "numpy.ndarray[Any, numpy.dtype[numpy.bool_]]"
It's unfortunate, but without higher-kinded typevars (python/typing#548) I see no way of fixing this issue.
The problem is that, when working with typevars, we've no way of decoupling the type from its parameters
(i.e. shape and dtype). So we can currently type that the addition of a float and int array returns a float array,
but we cannot do the same for ndarray subclasses (unless you explicitly override the subclasses' methods,
that is).
test-mypy-numpy.py:14: note: Revealed type is "numpy.ndarray[Any, numpy.dtype[numpy.bool_]]"
Interesting, the appearance of the boolean dtype most definitely looks like a mypy bug.
I would expect the type here to be ndarray[Any, Any] due to overload ambiguity, which is exactly what
happens with a: ndarray[Any, Any]; reveal_type(a + a).
After some trial and error I've managed to narrow the issue down (see below for a minimal example).
In short, there seem to be three requirements for triggering this mypy bug:
The function must be a method.
The method must be overloaded.
self must be annotated with a parametrized generic.
fromtypingimportAny, Generic, overload, TypeVar, TYPE_CHECKINGimportnumpyasnp_CharType=TypeVar("_CharType", np.str_, np.bytes_)
classCharArray(Generic[_CharType]):
@overloaddefstrip(self: CharArray[np.str_], chars: str= ...) ->CharArray[np.str_]: ...
@overloaddefstrip(self: CharArray[np.bytes_], chars: bytes= ...) ->CharArray[np.bytes_]: ...
ar: CharArray[Any]
ar_U: CharArray[np.str_]
ar_S: CharArray[np.bytes_]
ifTYPE_CHECKING:
reveal_type(ar.strip()) # E: Revealed type is "__main__.CharArray[numpy.str_]"reveal_type(ar_U.strip()) # E: Revealed type is "__main__.CharArray[numpy.str_]"reveal_type(ar_S.strip()) # E: Revealed type is "__main__.CharArray[numpy.bytes_]"
Activity
BvB93 commentedon Oct 9, 2021
It's unfortunate, but without higher-kinded typevars (python/typing#548) I see no way of fixing this issue.
The problem is that, when working with typevars, we've no way of decoupling the type from its parameters
(i.e. shape and dtype). So we can currently type that the addition of a float and int array returns a float array,
but we cannot do the same for
ndarraysubclasses (unless you explicitly override the subclasses' methods,that is).
Interesting, the appearance of the boolean dtype most definitely looks like a mypy bug.
I would expect the type here to be
ndarray[Any, Any]due to overload ambiguity, which is exactly whathappens with
a: ndarray[Any, Any]; reveal_type(a + a).rdbisme commentedon Oct 9, 2021
Thanks @BvB936! So should I open an issue on the mypy tracker for the bool problem?
BvB93 commentedon Oct 11, 2021
Yes, though I'd recommend narrowing it down to a minimal reproducible example first.
vnmabus commentedon Oct 15, 2021
I think it is the same as #20099.
BvB93 commentedon Oct 16, 2021
@vnmabus it seems to be the case, yes.
After some trial and error I've managed to narrow the issue down (see below for a minimal example).
In short, there seem to be three requirements for triggering this mypy bug:
selfmust be annotated with a parametrized generic.BvB93 commentedon Oct 17, 2021
FYI, I just opened an issue on the mypy tracker (python/mypy#11347).
jorenham commentedon Jan 6, 2025
This is impossible without higher kinded typing, which isn't supported in Python:
python/typing#548