I'm strongly in support of this proposal.  Type annotations have really helped me write more correct code.

I started working on numpy type stubs a few months ago. I needed a mypy plugin to support shape-aware functions. Those whole thing is pretty tricky. Still very WIP, but I'll clean them up a little bit and opensource it shortly.


On Sun, Nov 26, 2017 at 1:58 PM, Stephan Hoyer <shoyer@gmail.com> wrote:
On Sat, Nov 25, 2017 at 3:34 PM Matthew Rocklin <mrocklin@gmail.com> wrote:
Thoughts on basing this on a more generic Array type rather than the np.ndarray?  I can imagine other nd-array libraries (XArray, Tensorflow, Dask.array) wanting to reuse this work.  For dask.array in particular we would want to copy this entirely, but we probably can't specify that dask.arrays are np.ndarrays.  It would be nice to ensure that the container type was swappable.

Yes, absolutely. I do briefly mention this in my longer doc (see the "Syntax" section). This is also one of my personal goals for this project.

This will be most relevant when we start working on typing support for array shapes and broadcasting: details like data types can be more library specific, and can probably be expressed with the existing generics system in the typing module.

After we do some experimentation to figure out appropriate syntax and semantics for array shape typing, I would like to standardize the rules for typing multi-dimensional arrays in Python. This will probably entail writing a PEP, so we can add appropriate base classes in the typing module. I view this as the natural complement to existing standard library features that make it easier to interchange between multiple multi-dimensional array libraries, such as memory views and the buffer protocol.

NumPy-Discussion mailing list