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)