Mypy is still in development. The current prototype supports type checking and running programs using a standard Python VM, i.e. there is no performance boost yet (development roadmap). A significant subset of Python features is supported.
Mypy switches to Python-compatible syntax!
2 Jul 2013: Mypy now has a Python-compatible syntax! The implementation is already self-hosting. Have a look at the rewritten Mypy Tutorial (formerly Mypy Overview), README and the code. Also updated the roadmap. Related blog post -Jukka
PyCon Update: Python-compatible syntax for mypy?
15 Apr 2013: I wrote a blog post about my PyCon visit and a new, Python-compatible syntax idea. The short summary is that mypy may get a 100% Python-compatible syntax in the future! Also Python 2.x support, structural subtyping and real multiple inheritance are being planned. -Jukka
Mypy at PyCon US 2013 (Santa Clara, CA)!
13 Mar 2013: I will present a poster about mypy at PyCon US this weekend. If you are coming to PyCon, you are welcome to come for a chat. -Jukka
def fib(n): a, b = 0, 1 while a < n: print(a) a, b = b, a+b
def fib(n: int) -> None: a, b = 0, 1 while a < n: print(a) a, b = b, a+b
You can freely mix static and dynamic typing within a program, within a source file or even within a single expression. No need to give up the flexibility of dynamic typing — use static typing when it gives you a benefit. Often the only changes in statically typed code are the addition of function type signatures. Mypy can infer the types of other variables. (The above example was adapted from the Python tutorial.)
Every mypy program is syntactically valid Python. Dynamically typed mypy is almost identical to normal Python; there's practically no learning curve if you know Python. The aim is to support most Python language constructs in mypy.
Mypy will support accessing Python modules from mypy programs. Most commonly used libraries also have statically typed interface definitions that allow the type checker to check code that uses the libraries.
An important long-term goal is improved concurrency without the GIL. We aim to eventually get rid of the Global Interpreter Lock (GIL) that is used in CPython in our new VM and allow parallel programs to take advantage of multicore processors within a single process (more about the approach). We plan to support a low-level programming model based on threads and other, more programmer-friendly models built on top of that. One is likely to be based on lightweight processes with disjoint heaps and message passing, inspired by Erlang. The concurrency model will also allow Java threads to be used on future JVM targets efficiently (but the main implementation will compile directly to native code).