Skip to content

Mypy reports error for different argument, than the one which is actually wrong #19289

Closed

Description

@jan-spurny

Bug Report

When using generic Callables as parameters, the error is correctly reported, but it's reported for different argument than the one which is in fact wrong.

To Reproduce

from typing import Callable, TypeVar, List

T1 = TypeVar('T1')
T2 = TypeVar('T2')

def bigfunc(
    a: int,
    b: T1,
    c: Callable[[T1], T2],
    d: Callable[[T2], str],
) -> None:
    res = d(c(b))
    print(f'{a=}, {b=}, {res=}')


# should be:
#   c_func(x: float) -> List[float]:
def c_func(x: float) -> None:
    pass

def d_func(y: List[float]) -> str:
    return str(y)

bigfunc(1, 0.1, c_func, d_func)

Expected Behavior

I would expect mypy to complain about 3rd argument (c - c_func).

Actual Behavior

Mypy complains about 1st argument, which is 100% correct (a: int)

a.py:24: error: Cannot infer type argument 1 of "bigfunc"  [misc]
Found 1 error in 1 file (checked 1 source file)

Your Environment

  • Mypy version used: 1.16.0
  • Mypy command-line flags: None
  • Mypy configuration options from mypy.ini (and other config files): None
  • Python version used: 3.11.2

Activity

  1. brianschubert commented on Jun 13, 2025

    @brianschubert
    Collaborator

    To clarify, it's complaining about the first type argument, not the type of the first argument. bigfunc takes two type arguments, one for each of T1 and T2. The error is stating that it failed to infer a value for the first one, T1.

    However, that's still wrong. It actually infers T1 fine and wittles the signature of bigfunc down to

    def [T2] (a: builtins.int, b: builtins.float, c: def (builtins.float) -> T2, d: def (T2) -> builtins.str)
    

    mypy then fails to infer a value for T2, which it sees as being the first type parameter of the refined signature.

  2. sterliakov commented on Jun 13, 2025

    @sterliakov
    Collaborator

    Can we just use tvar name instead of index? Names don't change when some generics are substituted, and are no less helpful for identification.

  3. jan-spurny commented on Jun 13, 2025

    @jan-spurny
    Author

    @sterliakov that would be great!

  4. added a commit that references this issue on Jun 18, 2025
    a48ffed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions