Python用绑定泛型类的TypeVar定义类时mypy推断异常咨询

这是mypy现有类型推断逻辑的能力边界导致的，和代码运行逻辑正确性无关，核心原因有两点：

1. mypy不会对绑定了泛型类型的TypeVar做内部类型参数的透传追踪。当你定义QueryT = TypeVar("QueryT", bound=Query[Any])时，在Client类的定义上下文里，mypy只知道q是符合Query[Any]上界的某个类型，不会预留逻辑等实例化时拿到QueryT的具体实参（比如Query[int]），再把Query内部的ResultT类型替换成int，同步更新类里其他相关属性的类型。
2. 不同属性访问路径走的推断逻辑完全独立：
   • c.q能正确推断为Query[int]，是因为你显式给Client传了泛型实参Query[int]，q的类型和QueryT直接绑定，不需要额外解包；
   • c.q.r能正确推断为int，是因为mypy先拿到了c.q的具体类型Query[int]，再顺着这个具体类型的类定义查属性r的类型，属于常规的链式属性查找；
   • self.r = q.r是在类定义阶段完成类型推断的，这时候q的类型还是带bound的TypeVarQueryT，mypy只能从boundQuery[Any]里拿到r的类型是Any，后续实例化时不会再回溯更新这个属性的类型，所以最终c.r被推断为Any。

你调整QueryT定义时遇到的几个异常，本质都是这套逻辑的延伸表现：

• 把bound设为Query[Union[int, str]]时报类型不匹配，是因为Python泛型默认是不变（invariant）的，Query[int]不被认为是Query[Union[int, str]]的子类型；这时候类上下文里从bound拿到的r类型是Union[int, str]，自然self.r就推断成这个类型。
• 把bound设为Union[Query[int], Query[str]]时不报错，是因为Query[int]本身属于这个Union的成员，符合bound要求，但类上下文里从Union类型取r，拿到的就是两个分支r类型的并集Union[int, str]，不会跟着你传入的具体实参收窄。
• 把QueryT改成直接带约束（传入Query[int], Query[str]作为TypeVar的合法值，而非用bound）时，mypy对这类约束TypeVar的实例属性推断支持更弱，没法从约束列表里提取稳定的属性类型，就会要求你显式给属性加类型注解，否则全部退化为Any。

• 优先直接透传底层泛型的类型参数，不要为了减少类型参数书写量，把整个泛型类包装成单个TypeVar。就像你最后测试的写法，Client直接泛化于ResultT，构造函数接收Query[ResultT]，这种写法对所有类型检查器都兼容，推断100%准确，不存在隐式的能力边界问题。哪怕底层泛型有2个甚至更多类型参数（比如最开始举例的Foo[T, U]），老老实实把所有需要的类型参数列在Generic里即可，类型可靠性比少写几个字符重要得多。
• 如果确实想减少重复书写长泛型参数的成本，用泛型类型别名做封装，不要用包装TypeVar的方案。Python 3.12+可以用type语句定义类型别名，低版本可以用TypeAlias，比如常用的Bar[int, str, bool]可以定义成别名BarIntStrBool，用到的时候直接写别名即可，既减少冗余，又不会破坏类型推断链路。
• 如果场景要求必须传入Query的子类（而不只是Query的泛型实例），必须用绑定泛型类的TypeVar时，要给类中所有和该TypeVar相关的属性显式写类型注解，不要依赖__init__赋值的自动推断。如果需要用到泛型内部的类型（比如这里的r的类型），还是要把对应的内部类型参数单独声明为类的泛型参数，没有捷径。
• 不要依赖链式属性访问的推断结果反推直接属性的类型，这两个推断路径在类型检查器里是完全独立的，运行时是同一个对象不代表类型检查阶段能拿到一致的类型。

内容的提问来源于stack exchange，提问作者Sargera