-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Class definition for D depends on itself - unable to figure out types #9391
Comments
This is a form of circular reference that pyright doesn't (and is unlikely to ever) support. Sorry. |
I'll note that mypy has not yet implemented support for class decorators. It completely ignores them. I think pyre may do the same. If and when they add support for class decorators, they'll probably also reject the above code. The expression |
I think that might actually be the best choice for the sake of codenav (gotodef, hover). What I've observed: (1) there are few typesafe ways to annotate a decorator correctly which changes function signature, and I haven't seen any for decorators which add/remove methods in a class. (2) Users usually get decorators wrong. (3) If we ignored decorators entirely, then Go-to-def and Hover would more often give the user what they wanted, i.e. reflecting the eventual runtime behavior of their program. Here, I picked a random example of a decorator that you wrote #774 (comment)
If you cmd+click on the named arguments "x1" or "y1" then pyright doesn't find a definition; if you cmd+click on the named arguments "x2" or "y2" then it does. So for cases where users get decorators right (like this one), and where they get them wrong, codenav would be better served by assuming the decorator doesn't exist. |
Pyright gets "Unknown" for the return-type of f, but Mypy and Pyre get "D.A".
Playgrounds: pyright, mypy, pyre
I also see #4518 "Class definition for "MyClass" depends on itself", but the repros there were non-deterministic and it seemed to be related to evaluation order. That issue was closed because of no clear repro.
I also see https://microsoft.github.io/pyright/#/mypy-comparison?id=circular-references "Because mypy is a multi-pass analyzer, it is able to deal with certain forms of circular references that pyright cannot handle." I don't know if this is an additional case of circularity that pyright can't handle?
My hope is that even if there's a type error in the declaration of
D
, I'd hope that the return type off
should still be solvable by pyright, so that hover and go-to-def onx.foo()
will succeed. In other words some way to still retain useful information aboutD
even in the presence of a type error, maybe even one that we suppress.(The code in this bug is a minimal repro of an idiom that's widely used in generated code at my company).
The text was updated successfully, but these errors were encountered: