The forward class annotations would not need need to be processed at runtime
and could be no-ops.
forward class A:
x: int
y: list[int]
A.__annotations__ could be empty. For a more complete example you could have,
forward class A:
value: B # This annotation is solely for type checker and
The problem comes solely from runtime introspection of type annotations. Static
typing does not need this nor do any exceptional cases occur. From
mypy/pyright/other type checker perspective there is not an issue to solve
here. dataclasses, pydantic, cattrs, click, and other libraries that
We could have forward part include all of method signatures/attributes which is
what a type checker needs. In theory we could do,
forward class Foo:
x: int
y: list[str]
def __init__(self, ...)
def process(self, data: list[float]) -> float: ...
and then later do continue class. If
My main question for this approach is how would this work with type checkers?
Is there any restriction that forward class's continuation must appear in same
module? If it's allowed that a forward class may be continued in a different
module I do not see how type checker like mypy/pyright could
I don’t see how this helps much in situations with nested callables which are
very common for decorators. I’m also unsure how this will work with situations
where input and output are both callables and the signature is modified using
paramspec. An example would be a decorator that adds/removes
I don't believe this is supported in pep 646 today. It was originally going to
be supported with a Map operator. With a Map operator it would let you do
something like,
T = TypeVar('T')
Ts = TypeVarTuple("Ts")
IndexedTuple = Tuple[Int, T]
def enumerage_args(*args: *Ts) -> *Map[IndexedTuple,
