Тип итератора — Любой в zip

Я не уверен, но думаю, что A не является достаточно общим (Iterable эквивалентно Iterable[Any]). Если вы добавите переменную типа к определению A, вы получите ожидаемый раскрытый тип.

T = TypeVar('T')

class A(Iterable[T]):
    _list: list[T]

    def __init__(self, *args: T) -> None:
        self._list = list(args)

    def __iter__(self) -> Iterator[T]:
        return iter(self._list)

Насколько я могу судить, знания возвращаемого типа A.__iter__ недостаточно для того, чтобы zip привязал int к собственной переменной внутреннего типа. Не знаю, можно ли это исправить или нет. (Отмечу, что PyRight также сообщает тип j как Unknown, который используется для различения различных вариантов использования Any.)

Случай PyRight проще, поскольку он не печатает строго zip: Type of "zip" is "type[zip[Unknown]]".

mypy (через typeshed) сообщает более полный тип, хотя он усложняется тем фактом, что обработка различного количества итераций, которые zip может принять, является перегрузкой. Соответствующий случай здесь

def [_T_co, _T1, _T2] (typing.Iterable[_T1`-1], typing.Iterable[_T2`-2], *, strict: builtins.bool =) 
   -> builtins.zip[tuple[_T1`-1, _T2`-2]]`

Когда вы делаете A полностью универсальным, mypy может «извлекать» int из типа a, чтобы связать int с _T2`-2.

Сравнение цикла for и объекта zip не является сравнением яблок с яблоками.

Для цикла

Как проверяется for i in X? По крайней мере, в текущем mypyисточнике цикл for проверяется путем поиска __iter__ подписи типа X и использования его возвращаемого типа. Таким образом, он не смотрит на ваше Iterable наследование, а находит ближайший __iter__ в MRO, который оказывается тем, который вы предоставили.

Почему это реализовано именно так? Цикл for — это собственная конструкция языка, определенная на синтаксическом уровне — в некотором смысле она более фундаментальна, чем существование некоторых типов протоколов, инкапсулирующих поведение итерации.

молния

Теперь zip — это просто класс. Он определяет свой собственный метод __iter__, поэтому for a,b in zip(A, B) будет проверяться в соответствии с типом возвращаемого значения. Этот класс является универсальным по типу итератора, поддерживая до 5 различных итераций и возвращаясь к общему случаю для 6 и более. Вот как это выглядит: напечатанная постоянная ссылка. Здесь нет никакой черной магии.

Я процитирую соответствующую часть:

class zip(Iterator[_T_co]):
    ...
    @overload
    def __new__(cls, iter1: Iterable[_T1], /, *, strict: bool = ...) -> zip[tuple[_T1]]: ...
    @overload
    def __new__(cls, iter1: Iterable[_T1], iter2: Iterable[_T2], /, *, strict: bool = ...) -> zip[tuple[_T1, _T2]]: ...
    ....

    def __iter__(self) -> Self: ...
    def __next__(self) -> _T_co: ...

(есть ветки, зависящие от версии, и другие перегрузки, я их здесь опущу для наглядности)

Вы столкнулись с перегрузкой с двумя аргументами. Он ищет _T1 и _T2, «решая» следующее уравнение:

Iterable[_T2] = A

Вот в чем виноват: вы заявляете, что A — это Iterable[Any]. Пропуск переменных универсального типа полностью эквивалентен использованию вместо них Any. Здесь нет места для вывода проверки типов. Итак, mypy радостно говорит: «Ух ты, я уже знаю это A <: Iterable[Any], следовательно, _T2 = Any, следующий». Он не трогает MRO и вообще не изучает семантику Iterable: он просто хочет знать, какой тип var должен его параметризовать.

На данный момент mypy уже знает, что A является подтипом Iterable[Any] — вы так сказали! Даже если ваш класс вообще не содержит __iter__, mypy уже сообщил бы об этом в определении, не нужно здесь повторяться. Было бы расточительно перепроверять соответствие протокола на каждом месте использования, а также возникло бы множество нежелательных ошибок. Представьте, что по какой-то странной причине у вас есть следующий класс:

class B(Iterable[str]):
    def __iter__(self) -> Iterator[int]: ...  # type: ignore[override]

Упс. Здесь это не имеет смысла, но может произойти в реальной жизни для более сложных протоколов. Если mypy проверять __iter__ везде, вам придется # type: ignore проверять все места, где B используется как Iterable[str].

Структурное подтипирование

Примечание: Iterableшарлатан как typing.Protocol. Если вы вообще не наследуете от него, ваш класс все равно может быть подтипом Iterable — это называется структурным подтипом. Это даже пройдет assert issubclass(A, Iterable)! Если вы не объявляете реализацию явно, средства проверки типов должны как можно точнее определить соответствующий тип. Таким образом, ваш случай, написанный без явного наследования Iterable, приведет к желаемому результату.

Общее примечание

Я понимаю вашу проблему с этим. На самом деле я также не уверен, что этот подход полностью оправдан: возможно, цикл for должен также обрабатывать итерацию как Iterable, решая то же уравнение? Но именно так ведет себя реализация в настоящее время, и оба подхода, по моему мнению, одинаково действительны.