8000 TYP: subtracting two np.ndarrays is of type NoReturn · Issue #20568 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

TYP: subtracting two np.ndarrays is of type NoReturn #20568

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking &l 8000 dquo;Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
twoertwein opened this issue Dec 11, 2021 · 3 comments
Closed

TYP: subtracting two np.ndarrays is of type NoReturn #20568

twoertwein opened this issue Dec 11, 2021 · 3 comments
Labels
00 - Bug 41 - Static typing

Comments

@twoertwein
Copy link

Describe the issue:

Subtracting two np.ndarrays is infered to "return" NoReturn.

See microsoft/pyright#2696 (comment) for @erictraut's analysis into why pyright infers NoReturn.

Reproduce the code example:

import numpy as np

reveal_type(np.zeros(1) - np.zeros(1))

Error message:

pyright: Type of "np.zeros(1) - np.zeros(1)" is "NoReturn"

NumPy/Python version information:

1.21.4, 3.9.6
@a-reich
Copy link
a-reich commented Dec 14, 2021

FWIW, with mypy I got Any for this instead of NoReturn.
But with np 1.22.0rc2, I get 'numpy.ndarray[Any, numpy.dtype[numpy.floating[Any]]]', which is almost fully accurate (except for not having the 64Bit part).

@BvB93
Copy link
Member
BvB93 commented Dec 15, 2021

The root of this issue lies in how overload ambiguity is handled (xref microsoft/pyright#2521). The difference between mypy and pyright is that the former will return Any in such a situation (as was noted in @a-reich's comment), while the latter will pick the first overload, i.e. the np.bool_-based one that returns NoReturn.

With the way pyright handles overload ambiguity it effectively means that the arrays dtype must be known, lest you'll end up with inro. This can be accomplished either via explicitly specifying the dtype yourself or via improving the dtype-typing support in numpy itself.

The good news is that the numpy 1.22 should help quite a bit here, and the specific example that you showed is now successfully inferred as returning an array with a np.floating-based dtype. The bad news is that dtype-typing is, quite frankly, non trivial and I expect that a significant number of gaps will remain for the foreseeable future (xref #19252), gaps that will be filled in with Any.

@twoertwein
Copy link
Author

Great to hear that 1.22.0rc2 resolves this almost perfectly!

@matangover matangover mentioned this issue Dec 17, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug 41 - Static typing
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@seberg @twoertwein @BvB93 @a-reich
0