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

TypeVar not assignable to itself in steam.py #6009

Closed
Gobot1234 opened this issue Sep 23, 2023 · 3 comments
Closed

TypeVar not assignable to itself in steam.py #6009

Gobot1234 opened this issue Sep 23, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@Gobot1234
Copy link

Describe the bug
I think I've managed to get myself down to the last few type bugs in my library and the last one that's confusing me is a TypeVar that's not assignable to itself when joining types to the return types.

image
but it is joinable when I use cast even though it should be for the same TypeVar. Unfortunately I can't figure out a minimal repro for it (sorry to keep sending these things I can't find minimal repros for).

Code

  1. git clone https://github.com/Gobot1234/steam.py
  2. poetry install
  3. open steam/chat.py scroll to a function involving MemberT

VS Code extension or command-line
pyright 1.1.328

@Gobot1234 Gobot1234 added the bug Something isn't working label Sep 23, 2023
@erictraut
Copy link
Collaborator

erictraut commented Sep 24, 2023

This is because you have a snarl of circular dependencies in your code.

  • The type MemberT has a bound of Member.
  • Member is parameterized by GroupT.
  • GroupT has a bound of Group | None.
  • Group uses GroupChannel as a type argument.
  • GroupChannel derives from Chat.
  • Chat derives from Channel which is parameterized with ChatMessageT.
  • ChatMessageT has a bound of GroupMessage | ClanMessage.
  • GroupMessage derives from ChatMessage.
  • ChatMessage is parameterized by MemberT.
    And we're in a cycle.

Pyright already handles many forms of circular dependencies, but it doesn't handle this one. I'll look for ways to extend the logic to handle this.

I noticed that you're importing a bunch of symbols under a TYPE_CHECKING conditional check. I'm guessing you did this to try to avoid runtime import circularities. That's just masking the fact that your code is not well layered. I recommend looking for ways to refactor your code so you can eliminate these TYPE_CHECKING conditions and eliminate circular dependencies. Consider enabling the reportImportCycles check and eliminating the errors it reports.

@Gobot1234
Copy link
Author

I'll see if I can get rid of them going forwards but I feel like there's not much I can do bar put everything in one massive file

@erictraut
Copy link
Collaborator

I'm going to close this as "won't fix". Try to eliminate the circular dependencies within your code.

@erictraut erictraut closed this as not planned Won't fix, can't repro, duplicate, stale May 21, 2024
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

No branches or pull requests

2 participants