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

[red-knot] understand type[a.X] in a type expression #14545

Closed
Tracked by #14172
carljm opened this issue Nov 22, 2024 · 0 comments · Fixed by #14825
Closed
Tracked by #14172

[red-knot] understand type[a.X] in a type expression #14545

carljm opened this issue Nov 22, 2024 · 0 comments · Fixed by #14825
Assignees
Labels
red-knot Multi-file analysis & type inference

Comments

@carljm
Copy link
Contributor

carljm commented Nov 22, 2024

We understand the type[C] special form in an annotation. This spells the type consisting of the class C itself (not instances of the class, but the class object itself) and all of its subclasses.

There are a limited number of syntactic forms allowed inside type[...]. We can use type[C] or type[a.C] to directly reference the class object C. We can use type[A | B] (or e.g. type[a.A | A.B]) as syntactic shorthand for type[A] | type[B]. We can't use e.g. type[foo()], even if foo were a function returning a class object.

Currently we only support the case where the subscript to type[...] is a Name AST node. That is, we support type[C] but not type[a.C]. This issue is to add support for the latter; that is, for the Attribute AST node.

We should support this (and test it) in the case where a is a module, and also the case A.B where A is a class and B is a nested class. We should also test a multi-level example type[A.B.C]. These should all be added as mdtests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants