-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
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
TrueMypy'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!