|
| 1 | +PEP: 781 |
| 2 | +Title: Adding __type_checking__ constant |
| 3 | +Author: Inada Naoki <songofacandy@gmail.com> |
| 4 | +Discussions-To: https://discuss.python.org/t/85728 |
| 5 | +Status: Draft |
| 6 | +Type: Standards Track |
| 7 | +Topic: Typing |
| 8 | +Created: 24-Mar-2025 |
| 9 | +Python-Version: 3.14 |
| 10 | + |
| 11 | + |
| 12 | +Abstract |
| 13 | +======== |
| 14 | + |
| 15 | +This PEP proposes adding a new keyword ``__type_checking__`` that serves the |
| 16 | +same purpose as ``typing.TYPE_CHECKING``. |
| 17 | +This constant is ``True`` when the code is being analyzed by a static type |
| 18 | +checker, and ``False`` during normal runtime execution. |
| 19 | + |
| 20 | + |
| 21 | +Motivation |
| 22 | +========== |
| 23 | + |
| 24 | +For libraries that may be used in scripts where startup time is critical, |
| 25 | +the time taken to import the ``typing`` module cannot be ignored. |
| 26 | + |
| 27 | +To avoid importing ``typing``, developers currently define a module-level |
| 28 | +variable ``TYPE_CHECKING = False`` or use code like |
| 29 | +``if False: # TYPE_CHECKING``. |
| 30 | +Providing a standard method will allow many tools to implement the same |
| 31 | +behavior consistently. |
| 32 | + |
| 33 | +Furthermore, this allows compilers to eliminate type-checking-only code at |
| 34 | +compile time. This reduces bytecode size and memory usage, |
| 35 | +and would help with writing type-hinted code for memory-constrained |
| 36 | +environments like WASM or micropython. |
| 37 | + |
| 38 | + |
| 39 | +Specification |
| 40 | +============= |
| 41 | + |
| 42 | +``__type_checking__`` is a keyword and its value is ``False``. |
| 43 | +It can be used in the same way as ``False``, except it can not be used as |
| 44 | +a matching pattern. |
| 45 | + |
| 46 | + |
| 47 | +Rational |
| 48 | +======== |
| 49 | + |
| 50 | +Difference from ``__debug__`` |
| 51 | +----------------------------- |
| 52 | + |
| 53 | +``__debug__`` is not a keyword, but a built-in constant. |
| 54 | +Not adding a new keyword is attractive, but it requires special handling in |
| 55 | +both the compiler and the runtime to change the value of the constant |
| 56 | +depending on the startup option. |
| 57 | + |
| 58 | +By implementing ``__type_checking__`` the same way as ``False``, |
| 59 | +we avoid the need for special handling in both the compiler and runtime. |
| 60 | +Therefore, making it a keyword is the simpler approach. |
| 61 | + |
| 62 | + |
| 63 | +How to teach this |
| 64 | +================= |
| 65 | + |
| 66 | +Add this note to the ``typing.TYPE_CHECKING`` document: |
| 67 | + |
| 68 | +> If you don't want to import ``typing``, you can use ``__type_checking__``. |
| 69 | +> Workarounds like ``TYPE_CHECKING = False`` or |
| 70 | +> ``if False: # TYPE_CHECKING`` are not recommended since Python 3.14. |
| 71 | + |
| 72 | + |
| 73 | +Resources |
| 74 | +========= |
| 75 | + |
| 76 | +.. [1] Previous discussion: https://discuss.python.org/t/76766 |
| 77 | +.. [2] Reference Implementation: https://github.com/python/cpython/pull/131641 |
| 78 | +
|
| 79 | +
|
| 80 | +PEP: 781 |
| 81 | +Title: Adding __type_checking__ constant |
| 82 | +Author: Inada Naoki <songofacandy@gmail.com> |
| 83 | +Discussions-To: |
| 84 | +Status: Draft |
| 85 | +Type: Standards Track |
| 86 | +Topic: Typing |
| 87 | +Created: [24-Mar-2025] |
| 88 | +Python-Version: 3.14 |
| 89 | + |
| 90 | + |
| 91 | +Abstract |
| 92 | +======== |
| 93 | + |
| 94 | +This PEP proposes adding a new keyword ``__type_checking__`` that serves the |
| 95 | +same purpose as ``typing.TYPE_CHECKING``. |
| 96 | +This constant is ``True`` when the code is being analyzed by a static type |
| 97 | +checker, and ``False`` during normal runtime execution. |
| 98 | + |
| 99 | + |
| 100 | +Motivation |
| 101 | +========== |
| 102 | + |
| 103 | +For libraries that may be used in scripts where startup time is critical, |
| 104 | +the time taken to import the ``typing`` module cannot be ignored. |
| 105 | + |
| 106 | +To avoid importing ``typing``, developers currently define a module-level |
| 107 | +variable ``TYPE_CHECKING = False`` or use code like |
| 108 | +``if False: # TYPE_CHECKING``. |
| 109 | +Providing a standard method will allow many tools to implement the same |
| 110 | +behavior consistently. |
| 111 | + |
| 112 | +Furthermore, this allows compilers to eliminate type-checking-only code at |
| 113 | +compile time. This reduces bytecode size and memory usage, |
| 114 | +and would help with writing type-hinted code for memory-constrained |
| 115 | +environments like WASM or micropython. |
| 116 | + |
| 117 | + |
| 118 | +Specification |
| 119 | +============= |
| 120 | + |
| 121 | +``__type_checking__`` is a keyword and its value is ``False``. |
| 122 | +It can be used in the same way as ``False``, except it can not be used as |
| 123 | +a matching pattern. |
| 124 | + |
| 125 | + |
| 126 | +Rational |
| 127 | +======== |
| 128 | + |
| 129 | +Difference from ``__debug__`` |
| 130 | +----------------------------- |
| 131 | + |
| 132 | +``__debug__`` is not a keyword, but a built-in constant. |
| 133 | +Not adding a new keyword is attractive, but it requires special handling in |
| 134 | +both the compiler and the runtime to change the value of the constant |
| 135 | +depending on the startup option. |
| 136 | + |
| 137 | +By implementing ``__type_checking__`` the same way as ``False``, |
| 138 | +we avoid the need for special handling in both the compiler and runtime. |
| 139 | +Therefore, making it a keyword is the simpler approach. |
| 140 | + |
| 141 | + |
| 142 | +How to teach this |
| 143 | +================= |
| 144 | + |
| 145 | +Add this note to the ``typing.TYPE_CHECKING`` document: |
| 146 | + |
| 147 | +> If you don't want to import ``typing``, you can use ``__type_checking__``. |
| 148 | +> Workaround like ``TYPE_CHECKING = False`` or |
| 149 | +> ``if False: # TYPE_CHECKING`` are not recommended since Python 3.14. |
| 150 | + |
| 151 | + |
| 152 | +Resources |
| 153 | +========= |
| 154 | + |
| 155 | +* Previous discussion: https://discuss.python.org/t/76766 |
| 156 | +* Reference Implementation: https://github.com/python/cpython/pull/131641 |
| 157 | + |
| 158 | + |
| 159 | +Copyright |
| 160 | +========= |
| 161 | + |
| 162 | +This document is placed in the public domain or under the |
| 163 | +CC0-1.0-Universal license, whichever is more permissive. |
0 commit comments