Guido van Rossum just yesterday announced that the first draft of PEP 484 is available for review. This Python Enhancement Proposal defines a standard type annotation syntax, which is heavily inspired by mypy, for type hinting. The plan is to get it included in Python 3.5.
I've been contributing to the design and editing process and am very excited about the prospect of mypy supporting a standard annotation syntax. That's why (in addition to holidays) there hasn't been much activity in the mypy repo during the last month or so. Fear not -- there's a lot of things happening around mypy.
The PEP does not define a type checker or many of the details needed to implement a type system -- it gives a syntax and basic guidelines, around which various tools such as type checkers (including mypy), IDEs and maybe even optimizing (JIT) compilers can be implemented. There is still a lot of room for mypy to experiment and innovate around type checking Python code.
Why This Is Great
A standardized syntax could be boon for mypy. Here are just some benefits:
- More people, projects and companies are likely to hear about and use a syntax that is standard. More users means more polish, more bugs fixed, and overall a better experience for everybody.
- 3rd party libraries are likely to adopt type annotations when there is a standard. Mypy will catch more bugs when you use these static-typing-aware libraries in your programs.
- Tools such as IDEs and documentation generators are likely to add support for standard type annotations.
- There will be less fragmentation caused by multiple incompatible type syntax languages. This makes things less confusing and reduces duplicate work.
How Does This Affect Mypy Features?
The PEP will have some direct implicitations for mypy. As it's still a draft, we don't know what the final proposal will look like, but some aspects of mypy, mostly syntax, will likely change. Here are some of the most prominent differences (some of these are not yet reflected in the PEP draft):
- The PEP uses Callable[...] instead of Function[...] for callable/function types.
- Generic types are not valid in expressions. So code like
x = List[int]()will be written like this (this has been supported by mypy since the early days):x = [] # type: List[int]Syntax for type annotations is still being discussed, and this is clearly one of the more controversial aspects of the proposal. - typevar is spelled TypeVar and has other syntactic changes.
- Function overloading (@overload) is only available in library stubs. A future PEP may add runtime support for function overloading or multiple dispatch, but for now there's not going to be overloading for user code. This isn't really a major issue, since other mypy features such as union types (which are a recent addition and part of the PEP) make overloading rarely useful any more.
- There's provisions for explicit type checking of None values. Currently mypy implicitly makes None compatible with every type, but this is likely going to change. For example, Optional[int] would be used for int or None (same as Union[int, None]).
- There's a new type for variable length tuples: Tuple[int, ...] ('...' is part of the syntax).
- Type arguments of generic types in function annotations will be available for introspection. Currently List[int] evaluates to just list which loses information at runtime.
I've added a bunch of issues that cover differences between the PEP and mypy.
Join the Discussion
Join the discussion of open PEP issues and suggest changes at https://github.com/ambv/typehinting!
