-
Notifications
You must be signed in to change notification settings - Fork 162
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
mypy cannot find type-specific functions #960
Comments
Can you provide the commands options passed to mypy and make a minimal reproducible example? Currently our library is only partially typed. This means that only some type stubs are available, while the others they use the function signature from Rust which is not very informative. Some flags in mypy May affect how it interacts with partially typed packages |
|
See this repository for a broken example: https://github.com/Xemorr/RustworkXBrokenStubs |
Thanks for the minimal reproducible example. To fix the issue you need to add:
To your I hope that helps |
implicit_reexport = True
I still get I have pushed a version of that repository with that setting added |
Mypy probably cannot infer the types, you will need to type your function e.g. include |
I've added types, pycharm understands what's going on, mypy still has no idea. |
Indeed, |
implicit_reexport = True
--no-implicit-reexport
--no-implicit-reexport
Great, thanks for your work! |
This commit adds back the re-exports to the root `__init__.pyi` stub file. As was reported in Qiskit#960 the manual re-exports are necessary to ensure that mypy can find symbols in the root of the package, where most people use them, instead of off the inner `rustworkx.rustworkx` module.
* Finalize type signatures and enforce for all future functions This commit adds the last few missing type hints (primarily the generators module) and switches the CI configuration over to enforce that the library is completely type hinted. This makes it a CI error if a function or method is added that doesn't include type hints. This is all built on the hard work of @IvanIsCoding who built up all the type hinting infrastructure and stub files for the majority of rustworkx. This is just the last piece to enforce the library is fully typed moving forward. Co-authored-by: Ivan Carvalho <[email protected]> * Fix lint * Add missing stubs and run on full package * Fix to_dot() and graphviz_draw() hints * Fix lint * Fix search function hints * Fix full package stubtest This commit fixes most of the package for stubtest to work. This primarily involves having the stubfiles match the package layout. Unfortunately this means we need to put the majority of the type hints in the stubfile for `rustworkx.rustworkx`. Having the stubfiles split up as before mypy complains that the module doesn't exist. For example, having the coloring functions in `rustworkx/coloring.pyi` causes a mypy error that `rustworkx.coloring` couldn't be imported. This causes the rustworkx.pyi file to be quite large, but I couldn't find a pattern to workaround this limitation. Aside from that a bunch of stubs needed to be updated as now that they're getting included in the stubtest run issues were caught. The one exception is the generators module where the custom `text_signature` set in the function definitions were incorrect and tripping up mypy, these were fixed by removing the `text_signature` fields. * Ignore matplotlib type checks * Add back type hints lost during rebase * Add stub file for matplotlib visualization * Bump mypy version used in tests * Add stub file for graphviz too * Fix last failure * Fix typo * Use typing_extensions for mpl_draw type hints * Add re-exports to root __init__.pyi This commit adds back the re-exports to the root `__init__.pyi` stub file. As was reported in #960 the manual re-exports are necessary to ensure that mypy can find symbols in the root of the package, where most people use them, instead of off the inner `rustworkx.rustworkx` module. * Add release note * Add type check ignore to mpl for 3.8 failures * Fix release note typo --------- Co-authored-by: Ivan Carvalho <[email protected]>
Information
What is the current behavior?
PyCharm will think a method exists, I'll go to use it and then run mypy against it, mypy then says "Module has no attribute "graph_dijkstra_shortest_paths" [attr-defined]"
What is the expected behavior?
Mypy would understand the error
Steps to reproduce the problem
I have not been able to get to the bottom of why this is happening, the mypy version is 3.9 not 3.7, so is not a duplicate of that issue.
I just pip installed rustworkx, added 0.13.1 to my requirements file and then tried to use it in our codebase.
The text was updated successfully, but these errors were encountered: