# PEP 781: Make \`\`TYPE\_CHECKING\`\` a built-in constant

**URL:** <https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728>\
**Category:** PEPs\
**Tags:** typing\
**Created:** [March 24, 2025, 1:38am UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728 "2025-03-24T01:38:05Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![hal](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hal/32/26837_2.png) [@hal](https://discuss.python.org/u/hal)\
**Post date:** [March 26, 2025, 2:41am UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/21 "2025-03-26T02:41:00Z")

</div>

I like the principle of making the `if TYPE_CHECKING:` pattern cleaner, but I wonder if type checking could be one case of a more general pattern? It’s often recommended to use a multi-valued option rather than a boolean, so that the situations an option covers can be expanded over time.

If we had something like ` __mode__ `, we could use it to check for other modes of operation in addition to type checking. For example, I often think it would be nice to be able to include unit tests alongside the functions they cover, rather than in a separate module. I could imagine doing that with some kind of ` __mode__ ` enabled when pytest is running:

```python
def plural(singular_word: str, plural_word: str | None = None, *, count: int) -> str:
    """Get a plural or singular version of a word to describe `count`."""
    return singular_word if count == 1 else (plural_word or f"{singular_word}s")

if "pytest" in __mode__ :

    def test_plural() -> None:
        assert plural("example", count=1) == "example"
        assert plural("example", count=2) == "examples"
        assert plural("sheep", "sheep", count=2) == "sheep"
        assert plural("affix", "affixes", count=2) == "affixes"

```

If the interpreter was able to cheaply throw out the test block (or perhaps even strip it out at package-install time?) I wouldn’t feel bad about bloating a runtime module.

This is similar to the `if __name__ == "main":` pattern, but I’m imagining multiple modes could be enabled at once.

And for type checking, this could be something like:

```python
if "typechecking" in __mode__ :
    from typing_extensions import assert_type as assert_type
else:

    def assert_type(val: _T, typ: Any, /) -> _T:
        return val

```

What else could a mode be used for? Perhaps other expensive things done at runtime, like `@dataclass()` or enum definition as @steve.dower mentions above? e.g. if a module could handle pre-processing a ` __mode__ ` conditional block before runtime (e.g. at install or build time?), it could substitute a regular class definition for a dataclass or enum.

---

<div class="post-metadata">

**Author:** ![methane](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/methane/32/43_2.png) [@methane](https://discuss.python.org/u/methane)\
**Post date:** [March 26, 2025, 3:16am UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/22 "2025-03-26T03:16:50Z")

</div>

Thank you for your important feedback.

This PEP does not completely replace typing.TYPE\_CHECKING.  
Users using tools that utilize `typing.TYPE_CHECKING = True` can continue to use `typing.TYPE_CHECKING` as before.

I will add a note in the “Backward Compatibility” section about this use case.

> [@AA-Turner](#):
>
> It may be useful to survey the impact on runtime type checkers (e.g. @Jelle’s pyanalyze, or typeguard, beartype, etc).

All of pyanalyze, typeguard, beartype doesn’t use the pattern.

---

<div class="post-metadata">

**Author:** ![methane](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/methane/32/43_2.png) [@methane](https://discuss.python.org/u/methane)\
**Post date:** [March 26, 2025, 3:33am UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/23 "2025-03-26T03:33:10Z")

</div>

It is not easy as you think. typing uses much metaprogramming.

- Reimplement in C doesn’t reduce time to import other modules from typing.
- Metaprogramming part is really hard to port in C.
- Other Python implementations will use typing.py, instead of C implementation.

Additionally, this PEP can strip typing only code from bytecode. For example:

```python
# https://github.com/sqlalchemy/sqlalchemy/blob/dabd77992d785cad89ed110acd2f648a454fb7ae/lib/sqlalchemy/sql/elements.py#L133-L191

@overload
def literal(
    value: Any,
    type_: _TypeEngineArgument[_T],
    literal_execute: bool = False,
) -> BindParameter[_T]: ...

@overload
def literal(
    value: _T,
    type_: None = None,
    literal_execute: bool = False,
) -> BindParameter[_T]: ...

@overload
def literal(
    value: Any,
    type_: Optional[_TypeEngineArgument[Any]] = None,
    literal_execute: bool = False,
) -> BindParameter[Any]: ...

def literal(
    value: Any,
    type_: Optional[_TypeEngineArgument[Any]] = None,
    literal_execute: bool = False,
) -> BindParameter[Any]:
    r"""Return a literal clause, bound to a bind parameter.
    ...

```

This code creates 4 function objects.  
Three functions are registered for `typing.get_overloads()` and one function is for module namespace.

If you don’t need `typing.get_overloads()`, TYPE\_CHECKING can skip creating three functions for overload. But this PEP can strip all code objects for the three functions from the bytecode (pyc file).

Since Python 3.14, each def statement creates 2 function objects (one for annotation, see PEP 649).  
This would help WASM python users to write rich type hints.

---

<div class="post-metadata">

**Author:** ![hauntsaninja](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hauntsaninja/32/12451_2.png) [@hauntsaninja](https://discuss.python.org/u/hauntsaninja)\
**Post date:** [March 26, 2025, 3:39am UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/24 "2025-03-26T03:39:04Z")

</div>

I think it would be good for the PEP to summarise more of the discussion, e.g. to discuss potential alternatives.

- For instance, why not ask type checkers to treat any assignment like `TYPE_CHECKING = False` as defining a symbol that is true at type check time? mypy and pyright already do this.
- It would be also good to talk about the footguns of ` __type_checking__ / TYPE_CHECKING`. Use of this can totally break runtime typing and allows users to arbitrarily lie to type checkers. This to me makes it feel like a feature for advanced users, whereas being a builtin makes it something a lot of Python devs will encounter.

---

<div class="post-metadata">

**Author:** ![methane](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/methane/32/43_2.png) [@methane](https://discuss.python.org/u/methane)\
**Post date:** [March 26, 2025, 3:52am UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/25 "2025-03-26T03:52:34Z")

</div>

> [@hauntsaninja](#):
>
> - For instance, why not ask type checkers to treat any assignment like `TYPE_CHECKING = False` as defining a symbol that is true at type check time? mypy and pyright already do this.

I think motivation section describe it already.

> [@hauntsaninja](#):
>
> - It would be also good to talk about the footguns of ` __type_checking__ / TYPE_CHECKING`. Use of this can totally break runtime typing and allows users to arbitrarily lie to type checkers. This to me makes it feel like a feature for advanced users, whereas being a builtin makes it something a lot of Python devs will encounter.

I don’t think that topic is appropriate for this PEP. This issue is not caused by this PEP.  
If it is really a big problem, we should write a note in the documentation for TYPE\_CHECKING right now.

---

<div class="post-metadata">

**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\
**Post date:** [March 26, 2025, 8:49am UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/26 "2025-03-26T08:49:56Z")

</div>

Is it possible to use `TYPE_CHECKING` as the constant?

Right now it’s possible to avoid a `typing` import with:

```python
TYPE_CHECKING = False
if TYPE_CHECKING:
    from collections.abc import Iterable
    from typing import Any

```

It would be nice if we could keep using `TYPE_CHECKING = False`, and then when 3.14 is the lowest supported, remove `TYPE_CHECKING = False` altogether. I would not need to make any changes until October 2029 (when 3.13 is end-of-life).

This means I wouldn’t need to replace any code right now with ` __type_checking__ == False` or `try`/`except`, and make sure I’m using the right version of mypy.

If not, this could be added to the PEP’s rejected ideas.

---

<div class="post-metadata">

**Author:** ![srittau](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/srittau/32/237_2.png) [@srittau](https://discuss.python.org/u/srittau)\
**Post date:** [March 26, 2025, 11:15am UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/27 "2025-03-26T11:15:22Z")

</div>

> [@hugovk](#):
>
> Is it possible to use `TYPE_CHECKING` as the constant?

I much prefer a new dunder. `TYPE_CHECKING` is not only very shouty, the dunder makes it clear that this is a special Python builtin. `TYPE_CHECKING` is not going away any time soon, so it can still be used for the time being, until in a brighter future we’ll be able to use ` __type_checking__ `.

_Edit:_ That said, I believe ` __type_checking__ ` should be a variable, not a keyword. A keyword is not only unexpected, a variable offers an easier forwards-compatible path.

---

<div class="post-metadata">

**Author:** ![methane](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/methane/32/43_2.png) [@methane](https://discuss.python.org/u/methane)\
**Post date:** [March 26, 2025, 12:06pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/28 "2025-03-26T12:06:54Z")

</div>

It is difficult. `TYPE_CHECKING = True` is possible now and Sphinx does it.  
Making TYPE\_CHECKING constant breaks such code.

` __type_checking__ ` is much more rare, and it is reserved word.

---

<div class="post-metadata">

**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\
**Post date:** [March 26, 2025, 12:58pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/29 "2025-03-26T12:58:16Z")

</div>

Type checkers aren’t inspecting the value of `typing.TYPE_CHECKING` though - they’re substituting the entire meaning of specifically the `TYPE_CHECKING` that comes from `typing` (because type checkers are expected to replace _that entire module_ with their own internal/static logic, not to execute anything from inside of it).

If a new variable is added _anywhere_ besides the `typing` module, type checkers have to learn new rules about how to interpret it. Even if the name is `TYPE_CHECKING`, which is why assigning to `TYPE_CHECKING` doesn’t actually help the static checkers, and trying to cleverly assign it anything other than `False` also doesn’t help them.

Ultimately, `if False:` is just as good at avoiding actual execution while still having code included. Back when I was implementing type checking/code completions before the `typing` module existed, we _deliberately_ said that we’d still treat code under `if False` as if it executes, so that you could import things that are helpful for type analysis but unnecessary at runtime. The `typing.TYPE_CHECKING` constant is just the more readable version of this (and it more cleanly allows checkers to exclude code paths that they can determine will not be taken).

All of this means that type checkers need a literal `typing.TYPE_CHECKING` today, and defining ` __main__.TYPE_CHECKING` isn’t (or shouldn’t) help them - that’s just a regular variable that they have to deal with, and setting it to `False` in code should mean that `if __main__.TYPE_CHECKING` blocks are _excluded_ by the type checker (since they can determine that it’s always `False`).

**So the idea is that “code needed for the type checker but not needed for the rest of the code [runtime]” is protected by something that always evaluates to `False`, but the type checker knows to ignore regardless of value.**

All of which is why I favour ` __type_checking__ ` as a built-in variable that is allowed to be overridden by code. Because type checkers should always treat `if __type_checking__ ` blocks as if they are executed, and code that has to run on pre-3.14 can assign ` __type_checking__ = False` _unconditionally_ and the code will not be executed on any version.

> [@methane](#):
>
> `TYPE_CHECKING = True` is possible now and Sphinx does it.

I have no idea why Sphinx is doing this, but it will cause their interpretation of code to break. The biggest reason to protect code with `if TYPE_CHECKING` is to avoid circular imports (often required for type checking, but entirely unnecessary for Python).

I assume Sphinx is using `exec` or `import` to parse code (rather than `compile` or the `ast` module), in which case they aren’t a static type checker, and really ought to be skipping code intended only for static analysis.

---

<div class="post-metadata">

**Author:** ![Daverball](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/daverball/32/15931_2.png) [@Daverball](https://discuss.python.org/u/Daverball)\
**Post date:** [March 26, 2025, 1:08pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/30 "2025-03-26T13:08:39Z")

</div>

> [@steve.dower](#):
>
> I assume Sphinx is using `exec` or `import` to parse code (rather than `compile` or the `ast` module), in which case they aren’t a static type checker, and really ought to be skipping code intended only for static analysis.

@AA-Turner already addressed this point above:

> [@AA-Turner](#):
>
> Speaking for Sphinx, as one of the few users of `TYPE_CHECKING = True`, we will adapt if this PEP is accepted – there is a long term ambition to move to static based (CST/AST) introspection for autodoc, but just a lack of resource to do so – please don’t block the PEP on us.

---

<div class="post-metadata">

**Author:** ![ncoghlan](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ncoghlan/32/14266_2.png) [@ncoghlan](https://discuss.python.org/u/ncoghlan)\
**Post date:** [March 26, 2025, 2:14pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/31 "2025-03-26T14:14:09Z")

</div>

Regarding cross-version compatibility, `globals()[" __type_checking__"] = False` will allow the name to be set on older versions without causing a syntax error on newer versions (even with the simplest keyword based implementation).

Edit: that said, making ` __type_checking__ = False` a legal statement (without allowing any other form of assignment to that target) would also be straightforward.

---

<div class="post-metadata">

**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\
**Post date:** [March 26, 2025, 2:58pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/32 "2025-03-26T14:58:46Z")

</div>

I must be missing something. To me this feels like something that should absolutely be a variable in the built-in namespace. (With value False.) Why is that controversial?

---

<div class="post-metadata">

**Author:** ![AA-Turner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/aa-turner/32/4979_2.png) [@AA-Turner](https://discuss.python.org/u/AA-Turner)\
**Post date:** [March 26, 2025, 3:11pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/33 "2025-03-26T15:11:14Z")

</div>

I believe that the idea is to have it be exclusively and only `False`, to allow for compiler optimisations (e.g. reducing bytecode size).

Personally, I think making it a keyword is a mistake. I’d prefer to either have a normal variable in the built-in namespace, as you suggest, or to special-case the name to forbid assigning anything but `False` to it, to allow keeping the compiler optimisations. Either option is better than the keyword approach, in my view.

A

---

<div class="post-metadata">

**Author:** ![Jelle](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jelle/32/1049_2.png) [@Jelle](https://discuss.python.org/u/Jelle)\
**Post date:** [March 26, 2025, 4:09pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/34 "2025-03-26T16:09:06Z")

</div>

I’d rather not do this. I view `if TYPE_CHECKING:` as a hack. It’s a hack that’s necessary for some use cases, but if we’re talking about the evolution of the language, I’d prefer to make hacks unnecessary instead of embedding them in the grammar.

Here’s some ideas for what we can do to make `if TYPE_CHECKING` less important:

- Make annotations not evaluated by default. This is done in Python 3.14.
- Add a mechanism for lazy or typing-only imports. PEP 690 was rejected for being too magical, but I think there’s appetite for a more explicit version (`lazy import foo`?)
- Perhaps add a mechanism for lazy decorators, which are not executed at runtime. (One-minute idea: `@@final <newline> def foo(): ...` would make it so `foo. __decorators__ `, when accessed, evaluates to `[final]`.
- Look closely at what typing.py and other expensive modules do at import time and make it faster.

These are just a few half-baked ideas, but they can all help make Python code faster and more readable in general, without embedding a hack into the language definition.

---

<div class="post-metadata">

**Author:** ![Viicos](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/viicos/32/14616_2.png) [@Viicos](https://discuss.python.org/u/Viicos)\
**Post date:** [March 26, 2025, 4:34pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/35 "2025-03-26T16:34:00Z")

</div>

I follow @Jelle here, I think a _type import_ feature would fit better. Prior discussion:

- ["import type" statement to replace typing.TYPE\_CHECKING idiom and fix circular references](https://discuss.python.org/t/69518)
- [Lazy imports and PEP 649](https://discuss.python.org/t/48548) (with 10 reactions already).

While `typing.TYPE_CHECKING`/` __type_checking__ ` also allows code to be conditionally defined, it is most of the time to lie to the type checker.

---

<div class="post-metadata">

**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\
**Post date:** [March 26, 2025, 5:30pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/36 "2025-03-26T17:30:19Z")

</div>

> [@Jelle](#):
>
> I’d rather not do this. I view `if TYPE_CHECKING:` as a hack. It’s a hack that’s necessary for some use cases, but if we’re talking about the evolution of the language, I’d prefer to make hacks unnecessary instead of embedding them in the grammar.

I largely agree with this, but I don’t view it as a hack. I view it as a necessary tool in the absence of better, that has sharp edges when used to lie rather than used to avoid currently unresolved issues that arent the types themselves.\[1\]

Being a builtin name makes more sense to me than a keyword as a result. Pragmatism and acknowledging that we don’t have solutions that are shorter term here makes me lean toward adopting this, but no further. This shouldn’t be a constant, and we should look for more widely applicable ways to improve the situation. That could be `if False or __type_checking__ :` to get the existing `if False` optimizations while signaling to a typechecker the intent rather than making a ne long term constant.

> [@Jelle](#):
>
> Look closely at what typing.py and other expensive modules do at import time and make it faster.

I may have some changes to suggest for 3.15, but they’re too much to ask for for this close to 3.14, and _unfortunately_ attempts at benchmarking this in real world import-time-sensitive-use got delayed.

> [@Jelle](#):
>
> Perhaps add a mechanism for lazy decorators, which are not executed at runtime. (One-minute idea: `@@final <newline> def foo(): ...` would make it so `foo. __decorators__ `, when accessed, evaluates to `[final]`

Alternatively, since the only thing `@final` actually does is attempt to set `obj. __final__ = True`, we could case that as a classvar into the type specification as brought up [here](https://discuss.python.org/t/current-blockers-on-runtime-deferal-of-typing-imports/76843#p-219968-relevant-current-info-2)

> [@Jelle](#):
>
> Add a mechanism for lazy or typing-only imports. PEP 690 was rejected for being too magical, but I think there’s appetite for a more explicit version (`lazy import foo`?)

+1 to this. I think `type import foo` and `type import bar from foo` are the natural syntax here building on what we already have though? If runtime laziness is desired rather than deferral until introspection for module annotations, people can always inline an import instead.

* * *

1. If anyone wants some ideas on preventing the sharp edges, [here’s something I use in CI](https://github.com/mikeshardmind/async-utils/blob/main/_misc/_ensure_annotations.py) to ensure that the annotations I have are runtime valid even with the tricks I use to defer their evaluation

---

<div class="post-metadata">

**Author:** ![ajoino](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ajoino/32/6907_2.png) [@ajoino](https://discuss.python.org/u/ajoino)\
**Post date:** [March 26, 2025, 5:41pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/37 "2025-03-26T17:41:11Z")

</div>

I agree that this is not a hack and would rather see this small PEP implemented now than postpone it for a much larger more intrusive PEP that, considering how PEP 690 went, I’m sure would take a long time to reach consensus with still a fairly high chance of rejection.

---

<div class="post-metadata">

**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\
**Post date:** [March 26, 2025, 5:58pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/38 "2025-03-26T17:58:28Z")

</div>

I am in full agreement with Jacob here.

---

<div class="post-metadata">

**Author:** ![methane](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/methane/32/43_2.png) [@methane](https://discuss.python.org/u/methane)\
**Post date:** [March 26, 2025, 11:41pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/39 "2025-03-26T23:41:03Z")

</div>

Since one of motivation is compile time code elimination, ` __type_checking__ ` must not assignable like ` __debug__ ` is unasignable too.

```python
# a.py
if __type_checking__ :
    print("hello")

# b.py
import builtins
builtins. __type_checking__ = True
import a # Expect “hello" printed.

```

Unassignable builtin needs special casing in runtime. Unlike ` __debug__ `, ` __type_checking__ ` is always False. So using regular keyword like `False` is much simpler to implement. Zero code change for runtime.

This complexity is required not only for CPython, but also for other implementations. So adding unassignable builtin increase the complexity of language. That is why I chose regular keyword in the PEP.

The most controversial point is convenience until Python 3.13 goes EOL.

```python
# if __type_checking__ is unassignable at all
try:
    TYPE_CHECKING = __type_checking__
except NameError:
    TYPE_CHECKING = False # or from typing import TYPE_CHECKING

# if ` __type_checking__ = False` is allowed
__type_checking__ = False

```

Should we increase Python language complexity only for this convenience until 2030?

I thought “no” when writing the PEP. But I will reconsider it after implement it.

---

<div class="post-metadata">

**Author:** ![methane](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/methane/32/43_2.png) [@methane](https://discuss.python.org/u/methane)\
**Post date:** [March 26, 2025, 11:59pm UTC](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/40 "2025-03-26T23:59:00Z")

</div>

I think these improvement doesn’t useful to reduce pyc size.

See [my comment in previous thread](https://discuss.python.org/t/specify-type-checking-false-without-typing-import/76766/34).

SQLAlchemy doesn’t put all `@overload` into `if TYPE_CHECKING:` block. (They doesn’t need `typing.get_overloads()` except `execution_options` method. And `execution_options` method is not defined in the `elements.py`.)  
But replacing `TYPE_CHECKING` to `False` reduces ~10% pyc size already.

Additionally, as I said in [this comment](https://discuss.python.org/t/pep-781-adding-type-checking-constant/85728/23), PEP 649 doubles the number of function objects.  
So `if False` hack still save some RAM and import time.

Making type annotation zero cost without `if False` is really hard problem.  
I am not sure we can solve it within 10 years.

[Previous page](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728.md?page=1)

[Next page](https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728.md?page=3)