`TypeVar` defaults used instead of inferring from `Self` when passed to a generic function

[dsfaccini]

Summary

ty falls back to TypeVar defaults instead of inferring them from a self argument passed to a module-level generic function.

Playground link: https://play.ty.dev/0147ee60-169a-4d11-b364-ed8e350593a9

Repro (no external deps)

ty_repro_self_typevar_inference.py:

from typing_extensions import TypeVar, Generic

T = TypeVar('T', default=None)
U = TypeVar('U', default=str)


class Stream(Generic[T, U]):
    def handle(self, x: int) -> None:
        helper(self, x)


def helper(stream: Stream[T, U], x: int) -> None: ...

Run:

uvx ty check ty_repro_self_typevar_inference.py

Actual result

error[invalid-argument-type]: Argument to function `helper` is incorrect
 --> ty_repro_self_typevar_inference.py:9:16
  |
7 | class Stream(Generic[T, U]):
8 |     def handle(self, x: int) -> None:
9 |         helper(self, x)
  |                ^^^^ Expected `Stream[None, str]`, found `Self@handle`
  |
info: Function defined here
  --> ty_repro_self_typevar_inference.py:12:5
   |
12 | def helper(stream: Stream[T, U], x: int) -> None: ...
   |     ^^^^^^ -------------------- Parameter declared here
   |

Expected result

No diagnostic. helper's free TypeVars T and U should be solved from the passed self (whose type is Stream[T@Stream, U@Stream]). Instead ty resolves them to their defaults (None and str) and then reports that Self@handle is not assignable to Stream[None, str]. Pyright accepts this.

Notes

ty 0.0.29 (438a78d 2026-04-05) via uvx ty check. Closed #1977 had the same Self@method / TypeVar-default-fallback symptom but was triggered via Callable[[S], T | None] and fixed by ruff#22495 ("Generalize union-type subtyping fast path"). This repro uses neither Callable nor a union — just a direct helper(self, x) call with class TypeVars that have defaults — so #1977's fix does not cover it.

[carljm]

Thanks for the report!

For reference, this bug reproduces even if we use different typevars for the class vs the helper (I initially thought it might be a case where the repeat use of the same typevar causes a problem, but it doesn't appear to be).

[dsfaccini]

hey @carljm thanks for taking a look! glad to know this is valid :D I'm always a bit nervous reporting an issue on here bc I don't understand enough of the type system nor have the necessary vocabulary to make sure this wasn't already reported, but I regularly run ty against our pydantic-ai repo and check what I can pick out of the diagnostics bc I'd love to use it there as soon as it's compatible!

[carljm]

@dsfaccini reports are always welcome, please don't hesitate! Both your reports today are valid and very clearly presented!