The vision behind mypy

In our first blogpost, the main focus will lie on identifying what mypy’s properties are and for whom it is created. As a real system architect one could identify this as the vision of the project.

Wait what, static type checking for python?

It is true. Python has often been promoted as being a fast scripting-language. But what is less known, is that Python depends on solving errors in runtime: you have to run code before errors pop up. This can become a huge pain for developers, since they easily lose track of their custom-defined classes and types. Well… that used to be the case! mypy is a library which takes the responsibility of error checking and brings it back to compile time, or as its developers call it:

“A python linter on steroids”.

But why would an extreme linter be a good idea? Look at Javascript, like Python, a dynamically typed and widely used language. Research has shown that type-checking might resolve 15% of all errors up front¹. Think about how much time you would save by immediately getting these error messages while coding!

As Javascript tackles this problem with Typescript and others, Python offers a solution in mypy. Mypy gives users the possibility to check for type errors, before running the code. The well-known company Dropbox has posted their perspective on integrating mypy into their existing code-base. With integration into well-know IDE’s like VS Code, Pycharm and others, mypy might just make you consider using Python for your next project.

Mypy: A linter on steroids

Up until now we have talked a lot about types and type checking. Now we will elaborate on what mypy’s capabilities are.

Type annotations are used by the programmer to be able to type a given program variable. These type annotations defined in PEP 484 are treated as plain comments when the Python code is run, but mypy uses them to type check the program.

In mypy we can use different kinds of types which we are able to use in our annotations:

• Built-in types: such as the familiar int, char etc.
• Class types: classes re-usable as type.
• Built-in Collection types: like List[type], a Tuple[type, type] or a Mapping[type, type]. The type represents any generic type (or mapping) within the collection.
• Any types: when a type can have more than one type using i.e. Union or Optional.
• Generic types: implement a generic type derive from built-in types like List[T], for example a Stack.
• Miscellaneous types: described in the documentation. Which define annotation rules for cases where special types are necessary with for instance the async type.

For a complete overview of the kinds of types which can be used the documentation can be consulted. These type declarations, with the exception of some of the miscellaneous types, can all be used in defining the function arguments and the functions return type. It can also be used in classes for its attribute definition. A nice overview of examples of type annotations can be found in the mypy Cheatsheet.

With these type annotations, mypy processes the source code it is given and notifies the user whenever a type mismatch occurs in the expected type versus the type which is encountered at runtime. This can for example happen with variable assignments, function return types and passed function arguments.

Who are the people involved?

Similarly to writing a blog, knowing your audience in software architecture is also important. According to the Lean Architecture book written by James O. Coplien and Gertrud Bjørnvig ² there are five main stakeholder areas: end users, the business, customers, domain experts and developers. We will describe each of the stakeholder areas with respect to mypy.

End users -> developers and Python program users

The end users are both the developers using mypy as well as the users of Python programs. Developers of Python programs are also one of the main stakeholder areas, but a distinction can be made between an end user developer (using mypy to create better Python programs) and a developer as stakeholder (discussed below). The main advantage for the end users of Python programs is that their programs are more likely to work correctly. The main advantage for the developers of Python programs is that their knowledge of their programs is better and they are less likely to create bugs.

Customers -> collectives

Collectives (i.e. Companies, project groups and research institutes) using mypy can benefit from its usage. As stated before the usage of a typechecker in a dynamic language could possibly decrease the amount of bugs on average by 15%,¹ which in turn could result in less time searching for bugs and possibly decreases the development and debugging costs. One of the bigger customers in this case is Dropbox.

Domain experts -> maintainers

We think the main contributors of the mypy project and the people behind the merge requests can be identified as the domain experts. Looking at the contributors, 4 major contributors can be defined: Jukka Lehtosalo, M. Sullivan, I. Levkivskyi and G. van Rossum are maintainers of the repository. Their view on this product is possibly the most important and they define what the roadmap of mypy is (also look at The Future of mypy).

Developers -> contributors

Any developer willing to commit to the project is a stakeholder. For them it is important to have a clear view of what is needed in the project. Therefore the roadmap and the issue tracker are important tools to make sure each person willing to spend time in the project, knows what is left to do or where updates can be made.

The business -> Dropbox

Since mypy is fully free and open source using a creative commons license, no financial or business objective is present. It was started as a PhD project by J. Lehtosalo. One could argue that Dropbox is also the business side behind mypy, since their interest as customer stakeholder could be a source of increased revenue.

What can we expect from mypy in the future?

Although the static typechecking which is provided by the mypy library so far does a fine job in making Python a safer language, a downside is that currently in order to obtain the functionality of mypy, the user needs to go through the steps of installing mypy seperately. Currently mypy is seen more as an extension, seperate from Python making clever use of type declarations introduced in PEP 484.

On the other hand, its future context can be characterized as being integrated with the Python programming language, so that it becomes an internal language functionality that users of Python may adopt. The IDE’s should in the future context also be able to readily display the users errors when typing mistakes are made.

Besides having a future vision, mypy has a lot of users, which raises the need for a large amount of future extra content and fixes. The developers of mypy therefore have created a roadmap, which clearly states what they are currently working on and what they are planning to work on. The roadmap of mypy consists of bullet points which can be divided into three parts; bug fixes, general improvements and content addition. While one could go over each of the bullet points seperately, this would not provide any insight in the future perspective of mypy. Therefore we will discuss each of the three main parts in more detail.

Bug fixes

Logically, bug fixes are a large part of the roadmap. They are important because they make sure that code runs fluently and gives no issues when ran by other users. The bug fixes are tracked in the issues on the github page, where everyone can see and fix them. They focus mainly on making sure the functional requirements are met.

General improvements

Secondly, the roadmap of mypy will concentrate on improving the non-functional requirements of among others:

• the speed of mypy analysis
• the daemon, which runs the language server.
• the mypyc compiler, which is a native optimized version of mypy

These projects do not contribute to new features or bug-fixes of mypy, but make it faster and more optimized for use.

Feature addition

Lastly, the roadmap specifies what functional requirements are missing in mypy right now. The roadmap states that there are features (i.e. Support user defined variadic generics) which are not supported yet in mypy. Logically mypy would want these features added to fully support the needs of the end-user.

Coming up…

We as writers of this blog were impressed with the capabilities of mypy and the amount of different parties involved in mypy. While it is a simple program with a simple goal, the possibilities are endless! We look forward in researching more about this project for you and are definitely interested in diving deeper into the core of mypy. In our next blog post we will research how the vision of mypy influenced the architecture, so make sure you stay tuned!