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

Add option to rewrite numpy.ndarray as nptyping.NDArray #113

Open
sizmailov opened this issue Aug 29, 2023 · 5 comments
Open

Add option to rewrite numpy.ndarray as nptyping.NDArray #113

sizmailov opened this issue Aug 29, 2023 · 5 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@sizmailov
Copy link
Owner

Originated from #109 by @TheTripleV

@sizmailov sizmailov added enhancement New feature or request help wanted Extra attention is needed labels Aug 29, 2023
@auscompgeek
Copy link
Contributor

should really use numpy.typing, specifically numpy.typing.NDArray

@TheTripleV
Copy link
Contributor

Iirc numpy.typing leaves the size unspecified while ndtyping lets you type hint/(check?) the desired size.

@auscompgeek
Copy link
Contributor

oh, hmm. open numpy issue by the looks of things: numpy/numpy#16544

@sizmailov sizmailov changed the title Substitue numpy.ndarray -> nptyping.NDArray Add option to rewrite numpy.ndarray as nptyping.NDArray Aug 30, 2023
@sizmailov
Copy link
Owner Author

The question is, who would be the consumer of the resulting stubs?
The potential candidates are a programmer and a static analysis tool (IDE included).

For a human being, the shorter notation is preferable, so original pybind11 rendering is OK (more or less)
IDE and static analysis tools do not currently respect the dimensions but are strict on the format of the annotation.

It would be nearly impossible to make everyone happy at once. Therefore, there would be various "flavors" of stubs of the same library for different consumers until we have a universal standard.

The nptyping seems to implement runtime checks only.

I'm sure the runtime tools (nptyping included) never use stub *.pyi files directly. So, the consumer of stubs is still a programmer, but he can be spared from the burden of transformation from one notation to another.

I included the rewrite of np.ndarray as Annotated[np.ndarray, TYPE, FixedSize(DIMS) ] (enabled by --numpy-array-wrap-with-annotated-fixed-size option) as one that 1) relatively short 2) validates with mypy 3) preserves dimension information.

Another included rewrite removes all "generic" parameters (enabled by --numpy-array-remove-parameters). It does not preserve the type or dimension, but it's trivial to implement and allows it to pass static analysis checks quickly.

We can add more rewrites (enabled by separate mutually exclusive options) to accommodate a broader range of use cases.

I like numpy.typing.NDArray more since it's in the official package, but the shape annotation must be a(!) type(!) itself, the type required to be wrapped in numpy.dtype. So it's verbose and arbitrary (for the shape part)

The nptyping is not that vague, but probably it would not be in the mainstream.

I don't see much of a problem with having both of them.

@TheTripleV
Copy link
Contributor

The problem with Annotated for me is that the Vscode python extension doesn't show the information in annotated. I expect the majority of my users to be in vscode with Microsoft's python extension enabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants