Saturday, 17 January 2015

Mypy and the PEP 484 (Type Hinting) Draft

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!


  1. This may be off topic, but I have read the PEP and I'm especially interested in the section on Optionals. It's my understanding that the optional type hinting is documentation only, but I am interested to see whether it will turn into something more.

    I am a long time programmer (over 20 years now) and I have programmed in a lot of languages, Python being one of my all time favorites. I also love what Apple has done in the new Swift language and how they handle optionals.

    I actually wrote an article on implementing Swift style optionals in Python which details how Swift inspired me and my company to to change the way we handle optional values in Python.

    Here is the link to the post

    Perhaps there is some discussion to be had, or perhaps... as I said above, I may be off topic.

  2. Hi there, to get a feel for how the mypy syntax reads and feels in the real world, I would love to see some large codebases that have converted to it. Are you aware of any open-source projects that have, which could serve as examples? Thanks!

  3. What Is An Annotated Bibliography in MLA Format? An annotated bibliography in MLA format is a list of research sources with brief descriptions that are referenced in the Modern Language Association (MLA) format. Annotated bibliographies have each research source as a bibliographic entry, and contained within each entry is a paragraph or a few lines on the source itself. See more annotated bibliography generator apa


  4. خدماتنا متميزة عن غيرنا في مجال التسريبات سربات المياه والعوزال وحل بطرق سليمة دون التدمير فعندنا في شركة ركن البيت افضل يوجد افضل الفنين الممتزين في مجال التسربات والكشف عنها بدون اي مشاكل من خلال الطاقم التي تم تدريبه في شركة كشف تسربات المياه بالدمام فتعاملك معنا ستحصل علي خدمات متميزة

    شركة كشف تسربات المياه بجدة
    شركة كشف تسربات بجدة
    شركة عزل خزانات بالرياض
    شركة عزل اسطح بالرياض

    شركة كشف تسربات بالدمام
    شركة كشف تسربات بالرياض
    شركة كشف تسربات المياه بالرياض
    كشف تسربات المياه