@@ -983,6 +983,31 @@ Don't expect a checker to understand obfuscations like
983983``"".join(reversed(sys.platform)) == "xunil"``.
984984
985985
986+ Runtime or type checking?
987+ -------------------------
988+
989+ Sometimes there's code that must be seen by a type checker (or other
990+ static analysis tools) but should not be executed. For such
991+ situations the ``typing`` module defines a constant,
992+ ``TYPE_CHECKING``, that is considered ``True`` during type checking
993+ (or other static analysis) but ``False`` at runtime. Example::
994+
995+ import typing
996+
997+ if typing.TYPE_CHECKING:
998+ import expensive_mod
999+
1000+ def a_func(arg: 'expensive_mod.SomeClass') -> None:
1001+ a_var = arg # type: expensive_mod.SomeClass
1002+ ...
1003+
1004+ (Note that the type annotation must be enclosed in quotes, making it a
1005+ "forward reference", to hide the ``expensive_mod`` reference from the
1006+ interpreter runtime. In the ``# type`` comment no quotes are needed.)
1007+
1008+ This approach may also be useful to handle import cycles.
1009+
1010+
9861011Arbitrary argument lists and default argument values
9871012----------------------------------------------------
9881013
@@ -1174,7 +1199,7 @@ in expressions, while type comments only apply to assignments.
11741199
11751200
11761201NewType helper function
1177- -----------------------
1202+ =======================
11781203
11791204There are also situations where a programmer might want to avoid logical
11801205errors by creating simple classes. For example::
@@ -1644,6 +1669,8 @@ Convenience definitions:
16441669 forward references (which are given as string literals) as expressions
16451670 in the context of the original function or method definition.
16461671
1672+ * TYPE_CHECKING, ``False`` at runtime but ``True`` to type checkers
1673+
16471674Types available in the ``typing.io`` submodule:
16481675
16491676* IO (generic over ``AnyStr``)
0 commit comments