Hello again, I'm working on a library that uses the return type of methods at runtime to generate GraphQL types and I'm trying to deal with the case of circular imports and classes referencing each others. I was thinking of create a LazyType where you can pass the type name and the module, so that we are able to resolve the actual type at runtime without having to guess where it came from, like this: ``` import typing import strawberry if typing.TYPE_CHECKING: from .type_a import TypeA @strawberry.type class TypeB: @strawberry.field() def type_a(self, info) -> strawberry.LazyType["TypeA", ".type_a"]: from .type_a import TypeA return TypeA() ``` As previous post unfortunately I can't relay on sys.module, since the type is only imported when TYPE_CHECKING is True or inside the method. Now, I managed to make it work with a custom LazyType class, so the annotation above works; ``` strawberry.LazyType["TypeA", ".type_a"] ``` I don't dislike this to be honest, but looks like mypy isn't really happy, as you can see from the errors here: ``` tests/test_cyclic/type_b.py:13: error: "LazyType" expects no type arguments, but 2 given tests/test_cyclic/type_b.py:13: error: Invalid type comment or annotation tests/test_cyclic/type_b.py:16: error: Incompatible return value type (got "TypeA", expected "LazyType") ``` The first one could be resolve by using generics, but I'm not sure that's a good idea. The last one could be solved by creating a plugin, hopefully it won't be too difficult. But I have no clue about `Invalid type comment or annotation`. Why would that be the case? I noticed that the error disappears when removing the dot from the module name, but I'd like to be able to pass a dot there, so users of the library don't have to type the full module, since we can infer that. Any ideas? Or do I need to change the approach for this? Maybe doing a less typehint-y way: ``` def x() -> strawberry.LazyType("TypeA", ".type_a"): ``` Let me know! :)