Типы стёрты

Затем, что проверяет их не интерпретатор, а три других потребителя — и все три реальные.

Первый — человек. Сигнатура def process(data, config, retries) не говорит ничего; def process(data: list[Record], config: Config, retries: int = 3) -> Report отвечает на большинство вопросов, ради которых иначе пришлось бы читать тело.

Второй — статический анализатор. mypy находит целый класс ошибок до запуска: None, приехавший туда, где его не ждали; перепутанные аргументы одного типа; забытая ветка в match. Не все ошибки — но те, что находит, находит бесплатно и на всей кодовой базе сразу.

Третий — рантайм-библиотеки. И вот это самое недооценённое: аннотация — данные в словаре, и кто-то их читает.

from dataclasses import dataclass

@dataclass
class P:
    x: int
    y: int = 0

print(P.__annotations__)          # → {'x': <class 'int'>, 'y': <class 'int'>}
print(P(1, 2))                    # → P(x=1, y=2)

dataclass не проверяет типы — он читает __annotations__, чтобы узнать список и порядок полей, и генерирует __init__, __repr__, __eq__. На том же механизме стоят pydantic, attrs, FastAPI, SQLAlchemy 2.0, typing.NamedTuple.

То есть без аннотаций половина современного Python-стека просто не работает — не потому, что типы проверяются, а потому что они объявляют структуру.

Нельзя, и это не недоделка mypy, а следствие R2.

Надёжный (sound) анализатор обязан гарантировать: если проверка прошла, ошибки типа при исполнении не будет. Для этого нужно, чтобы тип объекта нельзя было изменить после проверки. В Python можно:

class A:
    def hello(self): return "A"

def use(a: A) -> str:
    return a.hello()          # mypy: всё в порядке

class B:
    def hello(self): return 1   # не str!

a = A()
a.__class__ = B                 # тип объекта поменялся на лету
print(use(a))                   # → 1, а обещали str

Добавь сюда setattr по вычисляемому имени, __getattr__, метаклассы, exec, C-расширения, которые могут подменить у объекта что угодно, — и станет ясно, что доказывать нечего.

Поэтому все анализаторы Python сознательно unsound: они находят большую часть реальных ошибок и молчат про остальное. Это инженерный компромисс, а не временное состояние. Any в системе типов — не заглушка, а честное «здесь доказательства нет».

Что из этого следует практически. Типы полезны, но не заменяют тесты. Данные, пришедшие снаружи — из HTTP, из базы, из файла, — надо валидировать в рантайме: там аннотация не говорит ничего вообще. И disallow_untyped_defs на новых модулях даёт больше, чем попытка вычистить Any из старых.

На границе процесса — почти всегда. Внутри — почти никогда.

Замер из этого урока: создание объекта через pydantic примерно в шесть раз дороже, чем через dataclass. Разница — это цена валидации: проверка типов, приведение, разбор вложенных структур, сборка сообщений об ошибках.

from dataclasses import dataclass
from pydantic import BaseModel

@dataclass
class D:
    x: int

class P(BaseModel):
    x: int

D(x="не число")      # → создаётся, поле остаётся строкой
P(x="не число")      # → ValidationError

Где платить стоит. Данные пришли снаружи и не проверены: тело HTTP-запроса, ответ чужого API, конфиг, строка из очереди, содержимое файла. Здесь аннотация не даёт ничего, а валидация — единственное, что стоит между чужими данными и вашим кодом. Шестикратная разница на объекте, который создаётся один раз на запрос, не измерима на фоне сети.

Где не стоит. Внутренние структуры, созданные вашим же кодом и уже проверенные на входе: узлы дерева, промежуточные записи, точки. Здесь валидировать нечего — данные пришли не снаружи, — а объектов миллионы. dataclass(slots=True) или NamedTuple.

Правило одной фразой: валидировать надо один раз, на границе, и дальше носить проверенные типы. Валидация в середине — это недоверие к собственному коду, оплаченное шестикратно.

Он разрешает конфликт между двумя правдами: типу нужен импорт, а рантайму — нет.

Ситуация типовая: модуль a аннотирует функцию классом из модуля b, а b импортирует a. Импорт ради аннотации создаёт цикл — при том что в рантайме он не нужен вовсе, аннотация всё равно не вычисляется.

from __future__ import annotations      # аннотации становятся строками
from typing import TYPE_CHECKING

if TYPE_CHECKING:                       # False при исполнении, True для mypy
    from heavy_module import Thing

def use(t: Thing) -> None: ...          # mypy видит тип, рантайм не импортирует

TYPE_CHECKING — обычная константа, равная False; анализаторы считают её True по соглашению. Никакой магии.

Два выигрыша. Разрыв цикла импортов — и время старта: тяжёлые модули, нужные только для аннотаций, не грузятся вообще. Урок 22 показывает, что import numpy стоит 88 мс; если он нужен только для типа в сигнатуре, платить незачем.

Цена. Всё, что читает аннотации в рантайме — get_type_hints, pydantic, FastAPI, — не найдёт имя и упадёт. Поэтому для моделей pydantic так делать нельзя, а для обычных функций можно.

Костыльность признана: PEP 649 (3.14) меняет модель на отложенное вычисление аннотаций по требованию, что убирает и необходимость в from __future__ import annotations, и большую часть случаев TYPE_CHECKING. Но старый способ проживёт ещё долго — R9.