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

Problem type checking ancestors() with pyright #1242

Open
jlhamilton777 opened this issue Jul 5, 2024 · 3 comments · May be fixed by #1246
Open

Problem type checking ancestors() with pyright #1242

jlhamilton777 opened this issue Jul 5, 2024 · 3 comments · May be fixed by #1246
Labels
bug Something isn't working

Comments

@jlhamilton777
Copy link

jlhamilton777 commented Jul 5, 2024

Information

  • rustworkx version: 0.15.1
  • Python version: 3.12.4
  • Rust version: 1.79.0
  • Operating system: Void Linux x86_64

What is the current behavior?

Pyright is unable to fully type check the rustworkx.ancestors() function in strict mode.

What is the expected behavior?

Pyright should be able to determine the type of ancestors(), including the parameterized type of the graph parameter.

Steps to reproduce the problem

# pyright: strict

import rustworkx as rx

graph: rx.PyDiGraph[int, float] = rx.PyDiGraph()
node = graph.add_node(7)
rx.ancestors(graph, node)
$ pyright .
./main.py
  ./main.py:7:1 - error: Type of "ancestors" is partially unknown
    Type of "ancestors" is "(graph: PyDiGraph[Unknown, Unknown], node: int, /) -> set[int]" (reportUnknownMemberType)
1 error, 0 warnings, 0 informations

I looked at the stub file

def digraph_dfs_edges(graph: PyDiGraph[_S, _T], /, source: int | None = ...) -> EdgeList: ...
def graph_dfs_edges(graph: PyGraph[_S, _T], /, source: int | None = ...) -> EdgeList: ...
def ancestors(graph: PyDiGraph, node: int, /) -> set[int]: ...
def bfs_predecessors(graph: PyDiGraph, node: int, /) -> BFSPredecessors: ...
def bfs_successors(graph: PyDiGraph, node: int, /) -> BFSSuccessors: ...
def descendants(graph: PyDiGraph, node: int, /) -> set[int]: ...

and graph doesn't have PyDiGraph[_S, _T] like in some of the other functions. I also ran into this issue with the descendants() function.

@jlhamilton777 jlhamilton777 added the bug Something isn't working label Jul 5, 2024
@IvanIsCoding
Copy link
Collaborator

We can replace the signature with PyDiGraph[Any,Any], but honestly that is a pyright quirk from microsoft/pyright#5101.

Mypy treat it as Any which is what we tested for. I’ll explore how Pyre and Pytype treat it so we can have a solution that works well with most type checkers

@IvanIsCoding IvanIsCoding changed the title Problem type checking ancestors() Problem type checking ancestors() with pyright Jul 5, 2024
@max-muoto
Copy link

We can replace the signature with PyDiGraph[Any,Any], but honestly that is a pyright quirk from microsoft/pyright#5101.

Mypy treat it as Any which is what we tested for. I’ll explore how Pyre and Pytype treat it so we can have a solution that works well with most type checkers

What might work well across type checkers is relying on type vars defaults in the typing extensions backport of TypeVar. You can default the keys/values to Any.

@IvanIsCoding
Copy link
Collaborator

We can replace the signature with PyDiGraph[Any,Any], but honestly that is a pyright quirk from microsoft/pyright#5101.
Mypy treat it as Any which is what we tested for. I’ll explore how Pyre and Pytype treat it so we can have a solution that works well with most type checkers

What might work well across type checkers is relying on type vars defaults in the typing extensions backport of TypeVar. You can default the keys/values to Any.

I think that is the best solution, although I am not going to backport a fix depending on typing_extension. So maybe for 0.16.x.

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.

3 participants