I was asked to write up some notes on what was discussed regarding aliases at the meetup the other week. Here is my best recollection of the salient points: --- The pyre team wants a more syntatically distinguished way to declare type aliases, for typechecker performance reasons. Łukasz Langa will be proposing (in a draft pep), syntax like `Foo: Alias[Bar]`. This has the advantages that (when using from __future__ import annotations) it needn't be executed and the names don't need to be imported at runtime. It has the disadvantage that such an alias can't be used in situations where a runtime type is actually required, such as using it as a base class (including as a type argument). It is also (in my opinion, at least) uglier. Another option brought up is `Foo = Alias[Bar]`. This can be implemented to allow using it as a base type, etc. One hiccup in this planning is that the current type alias syntax is in PEP 484 and widely used. It could be deprecated, but I think it is unlikely that mypy will drop support it? -- One thing that adding an explicit syntax for declaring aliases will allow us to do is create syntax for declaring a generic type alias that does not use all its type variables, or that uses them in a different order than they appear in the aliased type. mypy currently supports an undocumented version of this, "FlexibleAlias". `Foo = FlexibleAlias[T, U, V, Bar]` creates a type alias Foo with type parameters T, U, and V and type Bar, regardless of which of those variables occur in Bar or in what order. Currently we use this in mypy to allow changing certain types to Any under certain configuration flags: T = TypeVar('T') if MYPYC: Bogus = FlexibleAlias[T, Any] else: Bogus = FlexibleAlias[T, T] -Michael Sullivan (sully)