-
-
Notifications
You must be signed in to change notification settings - Fork 161
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
feat: add ArrayLike to xref #568
base: main
Are you sure you want to change the base?
Conversation
Seems fine to me; anyone else have any objections to this going in? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that the parameter descriptions are encouraged to be "for humans" rather than for type checkers, but ArrayLike
is pretty clear so no objection from me.
I'd probably link it to the :term:
like the others which includes a description of what array like means, but that's splitting hairs.
I suspect this part might actually matter depending on what |
Done! |
@@ -81,6 +81,7 @@ | |||
"np.ndarray": "numpy.ndarray", | |||
"array-like": ":term:`numpy:array_like`", | |||
"array_like": ":term:`numpy:array_like`", | |||
"ArrayLike": ":term:`numpy.typing.ArrayLike`", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"ArrayLike": ":term:`numpy.typing.ArrayLike`", | |
"ArrayLike": ":term:`numpy:array_like`", |
Here's the description of the term array_like
vs. the description of the term typing.ArrayLike
.
I still think the former is likely what you'd want to link to for users: it describes what array_like
means, as opposed to how the annotation is expected to behave in a static typing context.
Not a blocker though, feel free to do as you see fit!
No description provided.