Excited to slightly belatedly announce that PEP 613 is accepted! Thanks Guido for sponsoring + all of your help through the process.
Re: the generic aliases idea --
Currently Pyre doesn't properly support generic aliases... the proposed syntax sounds reasonable. This also helps solve the issue of making ordering of generics explicit for type aliases. For example, in
A = Dict[S, List[T]A: TypeAlias[S, T] = Dict[S, List[T]]
The explicit ordering is also related to classes inheriting from generic classes; Pyre has plans to require such classes to also inherit from `typing.Generic` in order to specify each type variable in the intended order. Making this explicit would help avoid quietly breaking a lot of downstream code when modifying class bases, etc.
From: Guido van Rossum <firstname.lastname@example.org>
Sent: Wednesday, January 29, 2020 11:16 PM
To: Ivan Levkivskyi <email@example.com>
Cc: Shannon Zhu <firstname.lastname@example.org>; email@example.com <firstname.lastname@example.org>
Subject: [Typing-sig] Re: PEP 613: Explicit Type AliasesSo I have another idea. Not sure if this should hold up PEP 613 or be a separate one or if it's just silly.
In mypy (not sure about pyre), if you write
T = TypeVar('T')
A = List[T]
then A becomes a *parametrized* type and must itself be instantiated as A[some_type], e.g. A[int] will mean List[T]. (Plain A means List[Any], unfortunately, for historic reasons.)
It's easy to forget this behavior and accidentally end up with an unintentional List[All]. Perhaps we could reinforce it by requiring
A: TypeAlias[T] = List[T]
and otherwise reject type vars in the RHS?