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 handle that. Classes are generally viewed as closed and fully defined within type checker. Monkey patching at runtime later is not supported. Libraries/techniques that rely on extending a class later tend to be sources of type errors/poor type checking coverage. ABC.register for dynamically declaring subclass relationship is similarly not supported by checkers. So without constraint that forward class must be continued within same module I think it's unlikely any type checker would support this technique. As main motivation is related to type annotations I think usage should be supported by type checkers.
One other edge case here is how would you forward declare an annotation for a type that like this, if TYPE_CHECKING: import numpy def f(x: numpy.ndarray) -> None: ... forward declaring ndarray here would not make numpy.ndarray available. Would you forward declare modules? Is that allowed? Looking at sourcegraph I do see a some module imports in TYPE_CHECKING blocks for purpose of using them as annotations. I'm confused in general how if TYPE_CHECKING issue is handled by this approach. Usually class being imported in those blocks is defined normally (without continue class) somewhere else. My current leaning lies towards pep 649 + smart eval strategy by get_type_hints that Carl proposed. _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/XNYKAEI6TSZU2EKQEM6AXDZOMVD3CPLS/ Code of Conduct: http://python.org/psf/codeofconduct/