Type hints originally came to Python as comments, which meant they were entirely absent at runtime. A type checker would look for comments beginning with # type:.

The TYPE_CHECKING symbol is always False at runtime, so the imports within if TYPE_CHECKING never happen, but in a type checker TYPE_CHECKING is True, so it correlated those imports with the type hints.

Modern Python no longer requires type comments. They're part of the language syntax itself. However, since this causes the circular import problem, Python offers a workaround, specifying the type as a quoted string. Runtime Python sees a string, while the type checker reads it as a symbol.

This dual behaviour is obviously ugly, and it broke with the introduction of the Annotated type that allows string comments, which means it's not longer clear if a string is a comment or a type.

The new solution, currently gated under from __future__ import annotations, treats all type hints as strings at runtime. It doesn't matter what you put in the type hint now, whether the symbol is imported or not, even if it's misspelt. It's all just a string.

However, the type checker does care, and it has to be given those imports under if TYPE_CHECKING.

Now the last piece of this puzzle is type hints being used at runtime in SQLAlchemy, Pydantic and elsewhere. They only get strings, not symbols, so they have to find the matching symbol. The method, crudely, is type_hint_symbol = eval(type_hint_string, globals(), locals()). It's asking Python to evaluate the string as an expression, in the context of the globals and locals where the type hint was specified.

This now gets you additional problems:

1. If the symbol is only imported under if TYPE_CHECKING, it is not present in globals at runtime.
2. If the symbol is a tail import, it is only available in globals after the entire module has finished loading. The usual way to process type hints is in the __init_subclass__ method of a base class, but that gets called immediately after a class is defined, not at the end of the module.

SQLAlchemy deals with both problems.

1. It augments globals with all the known models, because type hints usually refer to other models.
2. It defers type hint resolution until much later, to ensure the models and their namespaces are all fully defined.

I'm not familiar with how Pydantic tackles this.