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

Why not support a "by convention" use of nptyping? #74

Open
denisrosset opened this issue May 5, 2022 · 3 comments
Open

Why not support a "by convention" use of nptyping? #74

denisrosset opened this issue May 5, 2022 · 3 comments

Comments

@denisrosset
Copy link

For the people I work with, Pylance/Pyright support is important.

Would it be possible to use nptyping Shape annotations with Annotated, and document that possibility? note: that wouldn't require even importing the nptyping.

This could be done through the convention of having a string annotation in Annotated, or a dataclass wrapping a string.

Then the downstream tools such as beartype and typeguard could be modified easily to support this syntax, and other type checkers/code analyzers would simply ignore the additional information.

What do you think?

@ramonhagenaars
Copy link
Owner

You could use typing.Annotated as an alternative to nptyping, yes. Nothing will stop you from adopting the shape expression syntax:

from typing import Annotated
import numpy as np

Array2x3 = Annotated[np.ndarray, "2, [a, b, c]"]

def func(arr: Array2x3) -> None:
    ...

Having beartype and typeguard to do the instance checking is harder though. Because that would require beartype and typeguard to either implement the shape expression or depend on nptyping. Unless they offer some sort of plug-in or hooking mechanism, maybe @leycec from beartype knows?

@leycec
Copy link

leycec commented May 6, 2022

some sort of plug-in or hooking mechanism

You ask for much, misty mountain gorilla. I actually have a FIXME: comment to myself buried somewhere within the @beartype codebase begging myself to publicly expose a plugin API in a future release. After all, @beartype currently handles non-standard numpy.typing.NDArray[...] type hints by just internally reducing them to standard typing.Annotated[numpy.ndarray, beartype.vale.Is*[...]] type hints. So, we should let other typing enthusiasts (e.g., everyone here) do that too. 👍

Sadly, I myself am currently the plugin and hooking mechanism. Ask – and ye shall probably eventually receive! However...

Annotated[np.ndarray, "2, [a, b, c]"]

...that's pretty sketchy, bro. Ain't nobody dynamically evaluating, parsing, or otherwise munging ad-hoc strings embedded in type hints. On the other hand...

from nptyping import NDArray, Shape

# Perhaps this...
Annotated[np.ndarray, Shape['2, 2']]

# ...or maybe this!
Annotated[np.ndarray, NDArray[Shape['2, 2']]]

...are both much more sensible. I don't know quite enough about nptyping internals to know which @ramonhagenaars would prefer we support, however. Neither? Both? I leave the delicate decision in the capable sledgehammer-sized hands of the simian.

@denisrosset
Copy link
Author

denisrosset commented May 6, 2022

Indeed, simply tacking on a string is unwise.

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

No branches or pull requests

3 participants