Closed shoyer closed 4 years ago
Another option is for this repo to define a separate package called numpy_typing
or similar that includes a .py
defining these, so that users could do from numpy_typing import DtypeLike
. With PEP 561 implemented, mypy should be able to pick up the definitions of the aliases from numpy_typing
.
@JelleZijlstra That's a great alternative! Yes, we should definitely try the separate numpy_typing
package to avoid the need to make upstream changes in NumPy yet.
numpy-mypy has those: https://github.com/machinalis/mypy-data/tree/master/numpy-mypy
This can be done without adding a separate package and without from __future__ import annotations
(though that is certainly the neatest solution); the annotation just needs to be 'np.ShapeLike'
(e.g. a string).
I think we resolved all the issues here in https://github.com/numpy/numpy-stubs/pull/66.
These would indicate anything NumPy can coerce into the respective type:
DtypeLike
can be coerced into/withnp.dtype
ShapeLike
can be coerced intoTuple[int, ...]
ArrayLike
can be coerced intonp.ndarray
withnp.array
See https://github.com/numpy/numpy_stubs/pull/10 for (currently private) aliases
_DtypeLike
and_ShapeLike
.It would be nice to export these publicly for the benefit of downstream users.
The main complication is that this would likely also require adding these aliases to NumPy itself. Potentially, this could be unnecessary with
from __future__ import annotations
in Python 3.7 (PEP 564).