Thanks to visit codestin.com
Credit goes to github.com

Skip to content

TYP: Add typing for internal _tri extension #28755

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

Merged
merged 1 commit into from
Sep 7, 2024

Conversation

QuLogic
Copy link
Member

@QuLogic QuLogic commented Aug 23, 2024

PR summary

I'm not sure if we should start adding the full dtypes on np.NDArray.

PR checklist

@ksunden
Copy link
Member

ksunden commented Aug 23, 2024

Re: numpy type hints

I had avoided going there previously, partly because we mostly use ArrayLike, which is not subscriptable, and partly because I just didn't want to broach it yet.

I think starting with C-level interfaces for further specifying is reasonable, so I don't have a problem with adding it here.

Just to be sure, these are specifically ndarrays that must be passed, not any array like (lists of floats, etc.)?

The other part that is confusing about npt.NDArray is that it at least has space carved out to specify shape as well, though I don't think that is actually used... so while even in their examples they use the form like you have here, where there is a single parameter, which is the dtype, if you look at the repr of the object it is actually NDArray[Any, <dtype>].

In any case, I think what you have is likely correct, just was always one of the things that gave me a slight pause in trying to use the more specific numpy types.

@QuLogic
Copy link
Member Author

QuLogic commented Aug 26, 2024

I had avoided going there previously, partly because we mostly use ArrayLike, which is not subscriptable, and partly because I just didn't want to broach it yet.

I think starting with C-level interfaces for further specifying is reasonable, so I don't have a problem with adding it here.

Just to be sure, these are specifically ndarrays that must be passed, not any array like (lists of floats, etc.)?

Yes, these are all used internally only, and are called with normalized arrays, except for empty ones which are (), which I should correct in the type hints. Also, I kind of assumed that py::array would not coerce, but it does, so the tests also use lists, but I think it would be more consistent to fix those.

The other part that is confusing about npt.NDArray is that it at least has space carved out to specify shape as well, though I don't think that is actually used... so while even in their examples they use the form like you have here, where there is a single parameter, which is the dtype, if you look at the repr of the object it is actually NDArray[Any, <dtype>].

NDArray doesn't have a shape, but ndarray does. However, as far as I can tell, it's not used for anything yet.

In any case, I think what you have is likely correct, just was always one of the things that gave me a slight pause in trying to use the more specific numpy types.

@timhoffm timhoffm merged commit df1cfde into matplotlib:main Sep 7, 2024
44 checks passed
@QuLogic QuLogic deleted the tri-typing branch September 7, 2024 06:02
@QuLogic QuLogic added this to the v3.10.0 milestone Sep 7, 2024
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.

4 participants