Как манипулировать намеком встроенного типа

Mypy не использует __annotations__, то есть конструкцию времени выполнения. Анализ Mypy полностью статичен.

«встроенные» типы (аналогичные типы из стандартной библиотеки) получены из typeshed . Если вы хотите изменить эти типы для своих целей, вы можете (хотя я бы сильно отговорил его как решение вашей проблемы). Чтобы использовать пользовательский тип с mypy, вы можете сделать mypy --custom-typeshed-dir=/path/to/my/typeshed ..., а mypy будет использовать ваш модифицированный файл.

. Более эргономичное решение должно было бы сделать, как предлагает Азат, и написать обертку, которая перемещает сужение типа до функция полезности, так что локальная читаемость не страдает и вы сохраняете безопасность типов.

Я думаю, что здесь есть три разных варианта.

1. Первым вариантом является подход, предложенный в ответе Азата Ибракова : создайте вспомогательный метод, который явно выполняет проверку «Нет» во время выполнения, чтобы удовлетворить mypy. Это наиболее типичный вариант.
2. Второй вариант заключается в настройке mypy и ослаблении того, как он обрабатывает значения типа «Нет». В настоящее время mypy будет рассматривать «None» и «Element» как два разных типа: если у вас есть значение «None», оно не может быть «Элементом» и наоборот. Вы действительно можете ослабить это, указав mypy флаг --no-strict-optional, который сделает mypy обрабатывать значения типа «Нет» как член всех типов. Или, говоря иначе, если вы знакомы с такими языками, как Java, законно делать такие вещи, как это:

   String myString = null;
   

   Передача в флаг --no-strict-optional в mypy заставит его начать принимать код, как указано выше. Это, очевидно, означает, что ваш код будет меньше типов: mypy больше не способен обнаруживать потенциальные исключения «null pointer». Чтобы облегчить это, вы можете попробовать отключить строго-необязательный локально , а не глобально , создав конфигурационный файл mypy . В двух словах вы создадите конфигурационный файл, который выглядит примерно так:

   [mypy]
   # Global options can go here. We'll leave this empty since we don't
   # want to change any of the defaults.
   
   [mypy-mycodebase.my.xml.processing.module]
   # We weaken mypy in *just* this module
   strict_optional = False
   

3. . Третья опция - просто прекратить использование статической типизации для вашего XML-кода синтаксического анализа в целом: отбросьте переменную root быть типа «Любой» и отправиться в город. Затем, когда вы собираете полезные данные из своего XML, выполните все необходимые проверки времени выполнения, чтобы проверить ваши данные и создать объекты (typesafe!) Для хранения соответствующей информации. (Конечно, вы можете продолжать использовать статическую типизацию для остальной части вашего кода). Наблюдение здесь заключается в том, что любой вход во время выполнения будет по своей сути динамическим: пользователь всегда может пройти в некорректном XML, данные могут быть структурированы неправильно и т. Д. Единственный реальный способ проверки этих проблем - использовать проверки времени выполнения: проверка статического типа не поможет. Итак, если проверка статического типа обеспечивает минимальное значение в определенной области кода, зачем продолжать использовать ее там? Конечно, у этой тактики есть несколько недостатков. В частности, mypy не сможет обнаружить вопиющие злоупотребления API ElementTree, вам нужно быть достаточно внимательным к проверкам времени выполнения, чтобы убедиться, что плохие данные не ползут в регионы с проверкой типов вашего кода и т. Д. .