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

[meta] Fix type checking #10

Open
sneakers-the-rat opened this issue Aug 25, 2024 · 2 comments
Open

[meta] Fix type checking #10

sneakers-the-rat opened this issue Aug 25, 2024 · 2 comments

Comments

@sneakers-the-rat
Copy link
Collaborator

So type checking is the major question here - python type checking is static, this package is somewhat intrinsically about a hybrid of static and dynamic typing.

We currently hack around some of the limitations in the python typing system by autogenerating stub files, but thats a hack at best.

We also still are using the nptyping models despite having vendored them, and need to adapt and change those to new(ish, relative to nptyping, but old actually) python generic types and class_getattr - currently we get ruff errors for string literals as unresolvable types, which is bad.

So this is a catchall issue to start breaking up some of those concerns, recording problems, and planning a fix.

Fixing the linter errors seems like a first, low hanging fruit priority, and we may need to wait to python 3.14 for the functional type annotations to hit, but we should figure out a solid strategy for type checkers.

This doesnt impact the function of the package, but it certainly impacts its aesthetics and its adoptability - if someone needs to write a # noqa statement for every time they use NDArray, thats a bug.

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

2 participants
@sneakers-the-rat and others