Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ENH: Add annotations for np.core.shape_base #17644

Merged
merged 3 commits into from
Nov 1, 2020
Merged

Conversation

BvB93
Copy link
Member

@BvB93 BvB93 commented Oct 26, 2020

This PR adds annotations for the following functions in np.core.shape_base:

  • atleast_1d
  • atleast_2d
  • atleast_3d
  • vstack
  • hstack
  • stack
  • block

Copy link
Member

@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @BvB93, LGTM.

@rgommers rgommers merged commit 9bc70e7 into numpy:master Nov 1, 2020
@rgommers
Copy link
Member

rgommers commented Nov 1, 2020

One thing that has become clear to me is that these kinds of type annotations are not useful as documentation. The type annotations attempt to be very correct for all sorts of corner cases, like axis: SupportsIndex, which makes them very confusing to the average user (who should just see int). If IDE's are going to use type annotations instead of docstrings for this, that's going to be problematic. I'm not sure we have discussed this issue elsewhere already?

@BvB93
Copy link
Member Author

BvB93 commented Nov 1, 2020

If IDE's are going to use type annotations instead of docstrings for this, that's going to be problematic.

I feel that a fundamental problem here is that many (seemingly simple?) runtime behaviors cannot be conveniently expressed with static typing, thus forcing us to resort to the likes of axis: SupportsIndex (or worse: overloads).

@rgommers
Copy link
Member

rgommers commented Nov 1, 2020

I feel that a fundamental problem here is that many (seemingly simple?) runtime behaviors cannot be conveniently expressed with static typing

Yeah, this is partly historical. I'd much prefer to have axis only accept an int, and if static typing had existed when NumPy was first written, that's probably what the design would have been. Same with the array_like mess. Retrofitting static typing onto a too-forgiving code base is not ideal.

Maybe at this point it just is what it is, and it's on IDE's to do the right thing here (prioritize docs over annotations).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants