Accessing dunders via type object produces TypeVar clashes #14814

oremanj · 2023-03-01T17:32:16Z

Consider the following code:

from typing import AsyncIterator, TypeVar

T = TypeVar("T")

async def anext_via_instance(it: AsyncIterator[T]) -> T:
    return await it.__anext__()

async def anext_via_type(it: AsyncIterator[T]) -> T:
    anext = type(it).__anext__
    return await anext(it)

mypy happily accepts anext_via_instance, but in anext_via_type it fails with:

main.py:10: error: Incompatible return value type (got "_T_co", expected "T")  [return-value]
main.py:10: error: Argument 1 has incompatible type "AsyncIterator[T]"; expected "AsyncIterator[_T_co]"  [arg-type]

If I add a reveal_type(anext) in anext_via_type:

main.py:10: note: Revealed type is "def (self: typing.AsyncIterator[_T_co`1]) -> typing.Awaitable[_T_co`1]"

This behavior doesn't seem to be a recent change; it showed up on every version I spot-checked on the playground, and is still present on master. From the error message it looks like some kind of issue with TypeVar inference, but I'm not an expert.

(I'm trying to write something like anext_via_type in order to mimic the interpreter's behavior accessing a magic method in a specific circumstance; it won't accept an instance attribute, only a class attribute, so I don't want to accept an instance attribute either.)

The text was updated successfully, but these errors were encountered:

Fixes python#18024 Fixes python#18706 Fixes python#17734 Fixes python#15097 Fixes python#14814 Fixes python#14806 Fixes python#14259 Fixes python#13041 Fixes python#11993 Fixes python#9585 Fixes python#9266 Fixes python#9202 Fixes python#5481 This is a fourth "major" PR toward python#7724. This is one is watershed/crux of the whole series (but to set correct expectations, there are almost a dozen smaller follow-up/clean-up PRs in the pipeline). The core of the idea is to set current type-checker as part of the global state. There are however some details: * There are cases where we call `is_subtype()` before type-checking. For now, I fall back to old logic in this cases. In follow up PRs we may switch to using type-checker instances before type checking phase (this requires some care). * This increases typeops import cycle by a few modules, but unfortunately this is inevitable. * This PR increases potential for infinite recursion in protocols. To mitigate I add: one legitimate fix for `__call__`, and one temporary hack for `freshen_all_functions_type_vars` (to reduce performance impact). * Finally I change semantics for method access on class objects to match the one in old `find_member()`. Now we will expand type by instance, so we have something like this: ```python class B(Generic[T]): def foo(self, x: T) -> T: ... class C(B[str]): ... reveal_type(C.foo) # def (self: B[str], x: str) -> str ``` FWIW, I am not even 100% sure this is correct, it seems to me we _may_ keep the method generic. But in any case what we do currently is definitely wrong (we infer a _non-generic_ `def (x: T) -> T`). --------- Co-authored-by: hauntsaninja <hauntsaninja@gmail.com> Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>

oremanj added the bug mypy got something wrong label Mar 1, 2023

ilevkivskyi mentioned this issue May 19, 2025

Use checkmember.py to check protocol subtyping #18943

Merged

ilevkivskyi closed this as completed in #18943 May 30, 2025

ilevkivskyi closed this as completed in 3957025 May 30, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Accessing dunders via type object produces TypeVar clashes #14814

Accessing dunders via type object produces TypeVar clashes #14814

Uh oh!

Accessing dunders via type object produces TypeVar clashes #14814

Accessing dunders via type object produces TypeVar clashes #14814

Comments

Uh oh!