summaryrefslogtreecommitdiff
path: root/numpy/array_api/_constants.py
diff options
context:
space:
mode:
authorJosh Wilson <person142@users.noreply.github.com>2020-06-09 21:21:40 -0700
committerJosh Wilson <person142@users.noreply.github.com>2020-06-09 22:06:13 -0700
commit8e8a8f15970822a6242dc2ecba2ba4947204b4bb (patch)
tree49da0c63cda63cd7be9c0351f37be1f84cab727b /numpy/array_api/_constants.py
parentad30b31af0bb3fbfdc0f11486807edc76cec2680 (diff)
downloadnumpy-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