Type aliases with missing type arguments

[erictraut]

A recent change in pyright prompted a discussion about the correct interpretation of type aliases that refer to generic classes (or other generic type aliases) but omit the type arguments for that generic class/alias.

Examples include:

MyList = list
MyDict = dict | OrderedDict
ImmutableContainer: TypeAlias = Union[Mapping, Sequence]

There are several ways these statements could be interpreted.

1. These are simple variable assignments and should not be treated as implicit type aliases (unless an explicit TypeAlias annotation is present, in which case the missing type arguments should be treated as Any).
2. All of these statements should be treated as type aliases. The RHS should be treated consistently with other type annotations, and we should assume the missing type arguments are Any.
3. We should assume that the author intended for these to be generic type aliases, and the missing type arguments are "copied" from the type parameters of the referenced generic class/alias. In other words, MyList = list would be interpreted as MyList = list[_T].

Pyright was previously not treating these consistently. I recently made a change to apply interpretation 2 consistently, but this appears to have broken assumptions in some code. See this PR in typeshed.

Interpretation 3 is problematic because it's not only inconsistent with the way type annotations are interpreted everywhere else, but it also creates some challenging ambiguities. For example, should the generic type alias MyDict in the example above have four type parameters or two? The author probably intended two, but how would a type checker know this?

I'll add another possible interpretation:
4. We could apply rule 3 only in the case where the RHS consists of a single generic class or alias with no union or subscripts. In all other cases, we'd fall back to rule 2.

Option 4 strikes me as complicated and inconsistent, but it might be the best compromise.

We also need to consider whether the rules apply consistently between an implicit type alias and an explicit (PEP 613) TypeAlias.

Thoughts?

[AlexWaygood]

For discussion: here is how runtime Python currently treats this:

>>> d = dict[str, int]
>>> d[str, int]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: There are no type variables left in dict[str, int]
>>> e = dict
>>> e[str, int]
dict[str, int]

I would interpret the current runtime behaviour as implicitly endorsing Option 3.

But, perhaps the runtime behaviour should change.

[Akuli]

I like option 4, and I think I have used both MyList = list and MyGenericAlias = list[_T] | tuple[_T, ...] in typeshed. It feels like a "practicality beats purity" solution: Foo = list just looks right and should work, as it does at runtime, but generic type aliases are useful for more complex things.

[AlexWaygood]

Yeah, I also like Option 4 best, I think.

[erictraut]

I've decided to go with Option 4. This appears to be consistent with mypy's current behavior as well. Thanks for the feedback.

[superbobry]

Is it too late to revisit this decision? I agree that Option 4 is complicated and inconsistent, so it seems the logical resolution is to prefer the simpler and more predictable Option 2. Note that Option 2 is not just easier to support for tooling authors, but also easier for users to understand and remember.

I think it should be relatively straightforward to find and update all instances of bare generics in typeshed. So that should not be a factor in the decision making.

[kmillikin]

Yeah, we shouldn't coalesce around "complicated and inconsistent" to avoid telling the user they wrote some nonsense, even when the user is typeshed.

[erictraut]

I don't know if it's worth reopening the discussion about how to interpret implicit type aliases. Type aliases were underspecified in PEP 484. PEP 613 attempted to make them more explicit and deterministic, but it still left some parts unspecified. PEP 695 (if accepted) will be another step forward in terms of clarity and simplicity.

[superbobry]

I like PEP 695, but implicit type aliases will probably not be going away when and if it is accepted. So, I think it would still be useful to reopen the discussion and hopefully agree on a simple(r) interpretation.