[red-knot] Implicit type aliases in typeshed are widened as `Unknown | T`

[cake-monotone]

Some implicit type aliases in typeshed are not annotated using TypeAlias, such as:

# types.pyi
LambdaType = FunctionType
NotImplementedType = _NotImplementedType

# ctypes/wintypes.pyi
BYTE = c_byte
WORD = c_ushort
...
BOOLEAN = BYTE

Since these aliases lack explicit type annotations, Red-knot currently widens them as Unknown | T:

from types import LambdaType

reveal_type(LambdaType)  # revealed: Unknown | Literal[FunctionType]

[cake-monotone]

I’d like to get a sense of how this issue might be resolved in the future.

My guess is:

• Once TypeAlias support is fully implemented in Red-knot,
• These kinds of aliases (like LambdaType) will be treated as TypeAlias instances, not as just Literal[Class].
• TypeAlias instances are KnownInstance, and currently, the widening step is skipped for them.
• So the widening problem would no longer occur.

Is this understanding correct? Or is there something else going on that I might have missed?

[carljm]

The simplest short-term solution here is to extend our current special case for KnownInstance to also apply to KnownClass. I think it's hard to justify this on principled grounds, though, so we probsbly need to think through a more comprehensive solution. It may be that avoiding the widening for anything we identify as a potential type alias is workable.

[AlexWaygood]

I think a lot of these aliases-that-are-not-type-aliases should really be annotated with Final in typeshed. If we made this change in typeshed, it would probably benefit users of other type checkers as well as users of red-knot. Once we've implemented support for Final, it should mean that we use the inferred type as the public type directly for aliases like these, rather than using <inferred_type> | Unknown as the public type.

[carljm]

Maybe the right rule will be "assume all module-level assignments in typeshed are Final", pending a hopeful future where they are actually annotated that way.

I could also see some justification for always considering all module-level assignments in stub files to be implicitly Final? Since a stub file is more like a declaration of a typed module surface, rather than just being some Python code whose intention is less clear.

[Avasam]

I could also see some justification for always considering all module-level assignments in stub files to be implicitly Final? Since a stub file is more like a declaration of a typed module surface, rather than just being some Python code whose intention is less clear.

That makes sense to me. Just jumping in to say that in typeshed, such assignments are usually because it's simpler to replicate what the implementation does. Such aliases amount to saying "these two symbols will be the same".
If we expect it can be changed, then it would (should) be explicitly annotated with a type.