> I think that's on purpose, because the type annotations are quite complex.
> For reasons of correctness/completeleness, they use protocols, mixins, and
> overloads. Inside pure Python code, that would be harder to read and
> maintain.
I agree that NumPy type annotations are quite complex. However, having them
alongside the implementation might actually make maintenance easier, because
there will be no need to update type stubs separately from the implementation.
> IDEs should be able to deal with stub files anyway for compiled code (i.e.,
> the majority of NumPy), so that shouldn't be a fundamental issue right?
You are right, IDEs have to support type stubs anyway, but unlike type checkers
IDEs cannot always prefer type stubs to Python sources (if they are available),
because some IDE features need metadata which is *not* available in type stubs
(e.g. docstring and source location).
To make things a bit more specific, consider the following snippet
```
import numpy as np
np.array()
```
Here a user is in the middle of calling np.array and an IDE could render
* the signature(s) of np.array (available in type stubs)
* the docstring of np.array (available in Python sources)
* (maybe) the exact module where np.array is defined (available in both)
"Go to definition" on np.array should take the user to the implementation of
np.array or to both the implementation and the type stub.
Hovering over np.array would also need the signature and the docstring, but you
could also imagine it rendering e.g. a snippet of the implementation etc.
Sergei
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
