> 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(<CURSOR>) ``` 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
