reassignment of a `TypeAliasType` should not be evaluated as type expression

未关闭

#20,308 创建于 2025年11月28日 2 条评论 0 个 reaction 已指派 0 人在 GitHub 查看

还没有人认领这个 Issue。

评估

难度: 4/5
预计耗时: 3-5 天
新手友好度: 35/100

Issue 类型: 缺陷
描述清晰度: 基本清楚
活跃度: 停滞
技术栈: python
领域: devtools

调研方向

使用链接的 mypy-play 示例复现报告的行为，并比较 B = A 与 B = A[Any]，包括 strict 模式诊断和揭示的类型。跟踪涉及泛型 TypeAliasType 的赋值是如何解释的，然后添加有针对性的覆盖测试，表明重新赋值会保留别名对象，并且不会产生缺少类型参数的错误。

由索引模型根据 Issue 内容生成。

描述

bug

Unsurpringly, reassigning some generic TypeAliasType named A as B = A is not the same as subscripting it as B = A[Any]:

>>> type A[T] = T | str
>>> B = A
>>> type(A)
<class 'typing.TypeAliasType'>
>>> type(B)
<class 'typing.TypeAliasType'>
>>> A is B
True

Mypy's behavior (on master and 1.18.2) contradicts this:

type A[T] = T | T   # ✔️ true negative
B = A               # ❌ false positive: Missing type parameters for generic type "A"  [type-arg]

reveal_type(A)      # ✔️ mypy: "typing.TypeAliasType",      runtime: "typing.TypeAliasType"
reveal_type(B)      # ❌ mypy: "types.UnionType[Any, Any]", runtime: "typing.TypeAliasType"

https://mypy-play.net/?mypy=latest&python=3.12&flags=strict&gist=962d28cd59eff168c9cd2057e9f18f88

The error at line 2 is only reported in strict mode, so if you don't use that, I can imagine that it can be rather difficult to debug.

I realize that mypy interprets B = A as if it's B: TypeAlias = A, and it's not like there's nothing to be said for that. But I think that it's rather unlikely that a someone using the type keyword would expect that omitting it would result in the exact same behavior.
For _: TypeAlias that's a different story, and is currently working fine IMO; so I'm purely talking about TypeAliasType here. And given the differences in runtime semantics between the two, I think it's fair to treat them differently.

p.s. congratz with the 20k stars!