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

mypy cannot find type-specific functions #960

Closed
Xemorr opened this issue Aug 4, 2023 · 9 comments · Fixed by #963
Closed

mypy cannot find type-specific functions #960

Xemorr opened this issue Aug 4, 2023 · 9 comments · Fixed by #963
Labels
bug Something isn't working

Comments

@Xemorr
Copy link

Xemorr commented Aug 4, 2023

Information

  • rustworkx version: 0.13.1
  • Python version: 3.9
  • Rust version: N/A, not installed
  • Operating system: Ubuntu 20.04

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.

@Xemorr Xemorr added the bug Something isn't working label Aug 4, 2023
@IvanIsCoding
Copy link
Collaborator

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

@Xemorr
Copy link
Author

Xemorr commented Aug 7, 2023

python_version = 3.9
warn_unused_configs = True
no_implicit_optional = True
warn_redundant_casts = True
mypy_path = stubs/
disallow_untyped_defs = True
disallow_untyped_calls = True
warn_return_any = True
warn_unreachable = True
ignore_missing_imports = False
scripts_are_modules = True
plugins = pydantic.mypy
show_error_codes = True

@Xemorr
Copy link
Author

Xemorr commented Aug 7, 2023

See this repository for a broken example: https://github.com/Xemorr/RustworkXBrokenStubs

@IvanIsCoding
Copy link
Collaborator

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:

implicit_reexport = False

To your setup.cfg. This is because mypy on the stricter settings ignores our exports. Because most of our functions are defined in Rust, this is the easiest way to export everything without having to duplicate a lot of code

I hope that helps

@IvanIsCoding IvanIsCoding changed the title mypy not understanding type hints properly mypy cannot find type-specific functions with implicit_reexport = True Aug 7, 2023
@Xemorr
Copy link
Author

Xemorr commented Aug 7, 2023

I still get main.py:9: error: Function is missing a type annotation for one or more arguments [no-untyped-def]
with implicit_reexport = False in my small repository

I have pushed a version of that repository with that setting added

@IvanIsCoding
Copy link
Collaborator

implicit_reexport

Mypy probably cannot infer the types, you will need to type your function e.g. include name: string for the argument and -> rustworkx.AllPairsPathMapping for the return type

@Xemorr
Copy link
Author

Xemorr commented Aug 7, 2023

I've added types, pycharm understands what's going on, mypy still has no idea.
I'm running mypy main.py

@IvanIsCoding
Copy link
Collaborator

Indeed, mypy is ignoring our py.typed file completely and does not show any functions - even the one in the modules. #963 should help fix this, let's see

@IvanIsCoding IvanIsCoding changed the title mypy cannot find type-specific functions with implicit_reexport = True mypy cannot find type-specific functions with --no-implicit-reexport Aug 12, 2023
@Xemorr Xemorr changed the title mypy cannot find type-specific functions with --no-implicit-reexport mypy cannot find type-specific functions Aug 14, 2023
@mergify mergify bot closed this as completed in #963 Nov 22, 2023
@Xemorr
Copy link
Author

Xemorr commented Nov 22, 2023

Great, thanks for your work!

mtreinish added a commit to mtreinish/retworkx that referenced this issue Jan 21, 2024
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.
mergify bot pushed a commit that referenced this issue Jan 21, 2024
* 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 <ivancarv@student.ubc.ca>

* 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 <ivancarv@student.ubc.ca>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants