Что такое антипаттерны типизации в Python

Что проверяют

Работали ли вы с типами как с инструментом проверки, а не как с украшением сигнатур. Вопрос открытый, и по набору примеров видно, стоит ли у человека анализатор типов в сборке.

Как отвечать

Начните с главного: аннотации в Python ничего не проверяют во время исполнения, они нужны анализатору и читателю. Отсюда первый и основной антипаттерн: аннотации есть, а mypy или pyright в сборке нет. Такие подписи расходятся с кодом за пару месяцев и начинают врать.

Дальше перечислите частое:

• Any как способ заглушить анализатор: это не просто широкий тип, он выключает проверку для всего, что через него прошло;
• # type: ignore без кода ошибки и без объяснения, почему так;
• cast вместо честного разбора настоящего типа;
• слишком узкий вход: параметр объявлен как list[str], хотя функции хватило бы Iterable[str]. Для возврата правило обратное, конкретный тип удобнее;
• голые list и dict без параметра, а в новом коде ещё и typing.List вместо встроенных дженериков;
• строки вместо Enum, Literal или NewType: если идентификатор пользователя и артикул оба просто str, анализатор не поймает их перестановку;
• значение по умолчанию None при типе без допуска пустого значения.

Где спотыкаются

Считают, что аннотация валидирует данные. Сама по себе она не проверяет ничего, проверку во время исполнения делают отдельные библиотеки, и путать эти механизмы опасно: данные из внешнего мира останутся непроверенными.

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

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