-
Notifications
You must be signed in to change notification settings - Fork 7
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
More strict type checking #6
Comments
Sounds like a good idea. Related: we may want to add a |
These are the errors I get when I run
It looks like it's mostly issues with the numpy type hints. I'm not sure I understand where these type hints come from. It seems to think the |
They're shipped with numpy in That looks like a long list of errors, nice to fix but not super urgent I'd say. |
In numpy.array_api, we said that type checking that inputs were
Array
was too much overhead, and we would just rely on the the type signatures and type checking to do this.However, given that we are no longer thinking of this library as something that is used in production, I don't think we need to worry so much about the overhead of type checking. It might be a good idea to add explicit type checks to functions. This would prevent a sufficiently duck-typed object from silently passing through, although that's pretty unlikely since basically every function uses
x._array
on its input. The real reason would be to provide better error messages thatAttributeError
on bad inputs.Maybe this can be done automatically from the type signatures using one of those fancy libraries I know nothing about.
The text was updated successfully, but these errors were encountered: