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.

On Sat, Nov 25, 2017 at 6:31 PM, Matthew Rocklin <mrocklin@gmail.com> wrote:
Can you make a case for the usefulness numpy annotations? What benefits to you want to achieve and how will annotation aid in getting there.
  1. Error checking on large codebases with systems like MyPy
  2. Hinting and error checking at code-writing time with systems like Jedi "Hey, this function expects a 2-d square array but you just passed in a 3d array with irregular sizes"
  3. Supporting systems like the Cython compiler with type information, allowing them to speedup pure-python code without switching to the Cython language


On Sat, Nov 25, 2017 at 6:12 PM, Stephan Hoyer <shoyer@gmail.com> wrote:
On Sat, Nov 25, 2017 at 7:21 AM Marten van Kerkwijk <m.h.vankerkwijk@gmail.com> wrote:
A question of perhaps broader scope than what you were asking for, and
more out of curiosity than anything else, but can one mix type
annotations with others? E.g., in astropy, we have a decorator that
looks for units in the annotations (not dissimilar from dtype, I
guess). Could one mix annotations or does one have to stick with one
purpose?

Hi Marten,

I took a look at Astropy's units decorator:

Annotations for return values that "coerce" units would be hard to make compatible with typing, because type annotations are used to check programs, not change runtime semantics. But in principle, I think you could even make a physical units library that relies entirely on static type checking for correctness, imposing almost no run-time overhead at all. There are several examples for Haskell:

I don't see any obvious way to support to mixing of annotations for typing and runtime effects in the same function, though doing so in the same program might be possible. My guess is that the preferred way to do this would be to use decorators for runtime changes to arguments, and keep annotations for typing. The Python community seems to be standardizing on using annotations for typing:

Cheers,
Stephan

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion