Our great sponsors
-
ParlAI
Discontinued A framework for training and evaluating AI models on a variety of openly available dialogue datasets.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
I run a fairly large open source project (https://github.com/facebookresearch/ParlAI/) and we use mypy. Our experience has been that it can be quite difficult to placate, so we usually treat it only as a warning. However, having our code annotated with types in many places has significantly improved developer productivity, just from having less ambiguity with what you're dealing with.
mypy is actually compiled via mypyc, which should be a few times faster than interpreted Python https://github.com/python/mypy/tree/master/mypyc
I gave a presentation on type checking at the EuroPython 2017 where I also investigated how many Python projects really use type checking, I present the results at the end (35 minutes in):
https://www.youtube.com/watch?v=vM2Zoy4Sxhk&t=2181s
My conclusion was that only a small fraction of projects really used them, there were a lot of projects that had type checks in their code but only in "homeopathic" doses.
I started using them for some of my Python projects as well (e.g https://github.com/algoneer/algoneer) and while I find them useful I think they're not as useful as a "real" type system in a fully typed language like Golang. Still, they're very useful for discovering simple mistakes that would only show up in unit testing otherwise.
You can also "misuse" them for other purposes, at the end of the presentation I e.g. show how you can implement software contracts with them. Of course this would wreck a type checker like mypy, so don't do that in your codebase. That's probably also one of my critiques as the annotation syntax can in principle be used for anything, but mypy and other tools are not able to deal with code that does that.