Типизация и mypy

Что делают и чего не делают

Подсказки - это данные, приписанные к функции. Я их и достал: у функции есть словарь с типами аргументов и возврата. Интерпретатор их читает, хранит и НЕ проверяет - в этом весь смысл: язык остаётся динамическим, а проверка выносится наружу.

Проверку делает отдельный анализатор, который читает код и находит несоответствия ДО запуска. На моём примере он нашёл три ошибки, включая ту, что действительно упала бы в рантайме: обращение к методу у значения, которое может оказаться None. Заметь разницу: неверные типы аргументов рантайм проглотил молча, а вот None уронил программу - анализатор поймал оба случая заранее.

// Отсюда практическая ценность. Больше всего анализатор находит не «строка вместо числа», а именно случаи с None: функция может вернуть None, а вызывающий этого не ожидает. Это самая частая ошибка в динамическом коде, и она ловится ровно здесь, а не тестами.

подсказка типа

запись об ожидаемом типе; хранится как данные и в рантайме не проверяется

статический анализатор

читает код и находит несоответствия типов до запуска

Как внедрять в живой проект

Включить строгую проверку на большом проекте разом невозможно: она выдаст тысячи ошибок и её выключат в первый же горячий день. Рабочий порядок другой.

Начинают с мягкого режима на всём коде и с обязательной проверки только для НОВЫХ файлов. Потом включают строгость по модулям, начиная с ядра, где ошибки дороже всего. Отдельно добавляют пакеты с описаниями типов для внешних библиотек, иначе анализатор о них ничего не знает и молчит там, где мог бы помочь.

// И проверка обязана стоять в конвейере с блокировкой, иначе она превращается в украшение. Тот же приём, что и с другими проверками: зафиксировать текущее число ошибок как принятый долг и блокировать только рост. Это позволяет включить пользу сразу, а разбирать долг спокойно.

мягкий режим

проверка без строгих требований; точка входа для живого проекта

описания типов библиотек

отдельные пакеты, без них анализатор не знает про чужой код

Что описывать в первую очередь

Пользы больше всего от границ: публичные функции модулей, интерфейсы между слоями, данные, приходящие снаружи. Внутри короткой функции подсказки почти ничего не добавляют - там и так всё видно.

Отдельно стоит описывать структуры данных, которые ходят между частями системы. Тогда переименование поля или смена типа находится анализатором, а не в проде через неделю. Для этого берут классы данных или модели с проверкой значений - последние заодно проверяют данные в рантайме, что подсказки сами по себе не делают.

// И честная граница возможностей: анализатор не спасёт от неверной логики, не проверит данные, пришедшие из базы или по сети, и не заменит тесты. Он ловит ровно один класс ошибок - несостыковки типов, - зато делает это на всём коде и мгновенно.

границы модулей

публичные функции и интерфейсы между слоями; там подсказки полезнее всего

модель с проверкой

описание данных, которое проверяет значения и в рантайме

Как отвечать: «Проверяются ли аннотации типов во время выполнения?»

Нет. Они хранятся как данные - у функции есть словарь с типами аргументов и возврата, его можно прочитать, - но интерпретатор их не проверяет. Я специально показывал: функция, по подсказкам принимающая два целых, спокойно вернула склеенную строку при вызове с двумя строками. Проверку делает отдельный анализатор до запуска, и на том же файле он нашёл три ошибки. Самая ценная из них - обращение к методу у значения, которое может оказаться None: именно этот случай в рантайме и падает. Поэтому подсказки полезны в паре с анализатором в конвейере, а не сами по себе. Если нужна проверка данных именно в рантайме - например, того, что пришло по сети, - для этого берут модели с проверкой значений, потому что подсказки такого не делают.

Ответ отвечает прямо, показывает, где польза, и отделяет подсказки от проверки данных в рантайме. Последнее путают постоянно.

На чём валятся

• −Думают, что аннотации проверяются интерпретатором.
• −Ждут от анализатора проверки данных, пришедших извне.
• −Включают строгий режим разом на большом проекте и выключают его через неделю.
• −Не ставят проверку в конвейер, и она превращается в украшение.
• −Не добавляют описания типов для внешних библиотек и не понимают, почему проверка молчит.