Replies: 1 comment
-
This is related to #442. The problem is that nanobind ndarray annotations are quite expressive, and this doesn't map well onto the existing Python typing infrastructure (especially when considering that the library supports many nd-array frameworks besides NumPy). I'm interested in resolving this but don't quite know what's the best way to proceed. Perhaps you can take a look into #442 and chime in to see if we can find a solution that is agreeable to everyone? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm trying to upgrade to nanobind 2 and will love to get rid of my manually maintained .pyi files.
Below is a random snippet from the generated .pyi file which demonstrates the generated types used for the
Eigen::
matrix/vector types. These types are considered to beArrayLike
by nanobind's typegen.My previous manually maintained types used
numpy.typing.NDArray
everywhere -- and in fact if I string replace ArrayLike with NDArray in the generated .pyi file, it all seems to work as I want.ArrayLike
however, is apparently a MUCH broader type and leads to lots of type checking errors in my codebase which are spurious relative to the actual constraints I want the type system to enforce for my codebase.Definition of ArrayLike:
vs NDArray
I tried values like these in a pattern file but doesn't work ...
(NOTE: there's a typo in the nanobind docs -- and I've confirmed that the behavior I am trying to get doesn't happen even when using the correct argument to
nanobind_add_stubgen()
-- fix for the doc bug here: #631Beta Was this translation helpful? Give feedback.
All reactions