diff options
author | Josh Wilson <person142@users.noreply.github.com> | 2020-06-09 21:21:40 -0700 |
---|---|---|
committer | Josh Wilson <person142@users.noreply.github.com> | 2020-06-09 22:06:13 -0700 |
commit | 8e8a8f15970822a6242dc2ecba2ba4947204b4bb (patch) | |
tree | 49da0c63cda63cd7be9c0351f37be1f84cab727b /numpy/array_api/_constants.py | |
parent | ad30b31af0bb3fbfdc0f11486807edc76cec2680 (diff) | |
download | numpy-8e8a8f15970822a6242dc2ecba2ba4947204b4bb.tar.gz |
MAINT: make typing module available at runtime
Closes https://github.com/numpy/numpy/issues/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.
Diffstat (limited to 'numpy/array_api/_constants.py')
0 files changed, 0 insertions, 0 deletions