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.
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
# noqastatement for every time they use NDArray, thats a bug.