8000 Make `numpy.typing` available at runtime · Issue #16550 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Make numpy.typing available at runtime #16550

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 “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
person142 opened this issue Jun 9, 2020 · 0 comments · Fixed by #16558
Closed

Make numpy.typing available at runtime #16550

person142 opened this issue Jun 9, 2020 · 0 comments · Fixed by #16558
Assignees
@person142
Labels
01 - Enhancement 41 - Static typing
Milestone
1.20.0 release

Comments

@person142
Copy link
Member
person142 commented Jun 9, 2020 •
edited
Loading

Currently the numpy.typing module is only available at typing time; now that the stubs have been merged into NumPy we need to also make it available at runtime. See the mailing list discussion here:

http://numpy-discussion.10968.n7.nabble.com/Feelings-about-type-aliases-in-NumPy-td48059.html

as well as some more discussion here:

numpy/numpy-stubs#66

Reproducing code example:

from numpy.typing import ArrayLike

fails at runtime, but succeeds at typing time; i.e. you can do:

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from numpy.typing import ArrayLike

Make the first example work in all cases.
@person142 person142 added this to the 1.20.0 release milestone Jun 9, 2020
@person142 person142 self-assigned this Jun 9, 2020
@person142 person142 mentioned this issue Jun 10, 2020
Merged
person142 added a commit to person142/numpy that referenced this issue Jun 10, 2020
72D2
@person142
MAINT: make typing module available at runtime
8e8a8f1 
Closes numpy#16550.

This makes `np.typing.ArrayLike` and `np.typing.DtypeLike` available
at runtime in addition to typing time. Some things to consider:

- `ArrayLike` uses protocols, which are only in the standard library
  in 3.8+, but are backported in `typing_extensions`. This
  conditionally imports `Protocol` and sets `_SupportsArray` to `Any`
  at runtime if the module is not available to prevent NumPy from
  having a hard dependency on `typing_extensions`. Since e.g. mypy
  already includes `typing_extensions` as a dependency, anybody
  actually doing type checking will have it set correctly.
- We are starting to hit the edges of "the fiction of the stubs". In
  particular, they could just cram everything into `__init__.pyi` and
  ignore the real structure of NumPy. But now that typing is available
  a runtime, we have to e.g. carefully import `ndarray` from `numpy`
  in the typing module and not from `..core.multiarray`, because
  otherwise mypy will think you are talking about a different
  ndarray. We will probably need to do some shuffling the stubs into
  more fitting locations to mitigate weirdness like this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@person142 person142

Labels
01 - Enhancement 41 - Static typing
Projects
None yet
Milestone
1.20.0 release
Development

Successfully merging a pull request may close this issue.

ENH: make typing module available at runtime person142/numpy
1 participant
@person142
0