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.
We understand the
type[C]special form in an annotation. This spells the type consisting of the classCitself (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 usetype[C]ortype[a.C]to directly reference the class objectC. We can usetype[A | B](or e.g.type[a.A | A.B]) as syntactic shorthand fortype[A] | type[B]. We can't use e.g.type[foo()], even iffoowere a function returning a class object.Currently we only support the case where the subscript to
type[...]is aNameAST node. That is, we supporttype[C]but nottype[a.C]. This issue is to add support for the latter; that is, for theAttributeAST node.We should support this (and test it) in the case where
ais a module, and also the caseA.BwhereAis a class andBis a nested class. We should also test a multi-level exampletype[A.B.C]. These should all be added as mdtests.