使用 Mypy 检查 30 万行 Python 代码，总结出 3 大痛点与 6 个技巧！

Mypy 是什么？

（如果你很熟悉 Mypy，可跳过本节。）

Mypy 是 Python 的一个静态类型检查工具。如果你写过 Python 3，你可能会注意到 Python 支持类型注解，像这样:

def greeting(name: str) -> str:    return 'Hello ' + name

复制代码

Python 在 2014 年通过 PEP-484 定义了这种类型注解语法。虽然这些注解是语言的一部分，但 Python（以及相关的第一方工具）实际上并不拿它们来强制做到类型安全。

相反，类型检查通过第三方工具来实现。Mypy 就是这样的工具。Facebook 的 Pyre 也是这样的工具——但就我所知，Mypy 更受欢迎（Mypy 在 GitHub 上有两倍多的星星，它是 Pants 默认使用的工具）。IntelliJ 也有自己的类型检查工具，支持在 PyCharm 中实现类型推断。这些工具都声称自己“兼容 PEP-484”，因为它们使用 Python 本身定义的类型注解。

（译注：最著名的类型检查工具还有谷歌的pytype 和微软的pyright ，关于基本情况介绍与对比，可查阅这篇文章 ）

换句话说：Python 认为自己的责任是定义类型注解的语法和语义（尽管 PEP-484 本身很大程度上受到了 Mypy 现有版本的启发），但有意让第三方工具来检查这些语义。

请注意，当你使用像 Mypy 这样的工具时，你是在 Python 本身之外运行它的——比如，当你运行mypy path/to/file.py 后，Mypy 会把推断出的违规代码都吐出来。Python 在运行时显露但不利用那些类型注解。

（顺便一提：在写本文时，我了解到相比于 Pypy 这样的项目，Mypy 最初有着非常不同的目标。那时还没有 PEP-484（它的灵感来自 Mypy！），所以 Mypy 定义了自己的语法，与 Python 不同，并实现了自己的运行时（也就是说，Mypy 代码是通过 Mypy 执行的）。当时，Mypy 的目标之一是利用静态类型、不可变性等来提高性能——而且明确地避开了与 CPython 兼容。Mypy 在 2013 年切换到兼容 Python 的语法，而 PEP-484 在 2015 年才推出。（“使用静态类型加速 Python”的概念催生了 Mypyc，它仍然是一个活跃的项目，可用于编译 Mypy 本身。））

在 Spring 集成 Mypy

我们在 2019 年 7 月将 Mypy 引入代码库（#1724）。当首次发起提议时，我们有两个主要的考虑：

1. 虽然 Mypy 在 2012 年的 PyCon 芬兰大会上首次亮相，并在 2015 年初发布了兼容 PEP-484 的版本，但它仍然是一个相当新的工具——至少对我们来说是这样。尽管我们在一些相当大的 Python 代码库上工作过（在可汗学院和其它地方），但团队中没有人使用过它。

2. 像其它增量类型检查工具一样（例如 Flow），随着代码库的注解越来越多，Mypy 的价值会与时俱增。由于 Mypy 可以并且将会用最少的注解捕获 bug，所以你在代码库上投入注解的时间越多，它就会变得越有价值。

尽管有所犹豫，我们还是决定给 Mypy 一个机会。在公司内部，我们有强烈偏好于静态类型的工程师文化（除了 Python，我们写了很多 Rust 和 TypeScript）。所以，我们准备使用 Mypy。

我们首先类型化了一些文件。一年后，我们完成了全部代码的类型化（#2622），并升级到最严格的 Mypy 设置（最关键的是 disallow_untyped_defs ，它要求对所有函数签名进行注解），从那时起，我们一直维护着这些设置。（Wolt 团队有一篇很好的文章，他们称之为“专业级的 Mypy 配置”，巧合的是，我们使用的正是这种配置。）

Mypy 配置：https://blog.wolt.com/engineering/2021/09/30/professional-grade-mypy-configuration/

反馈

总体而言：我对 Mypy 持积极的看法。 作为核心基础设施的开发人员（跨服务和跨团队使用的公共库），我认为它极其有用。

我将在以后的任何 Python 项目中继续使用它。

好处

Zulip 早在 2016 年写了一篇漂亮的文章，内容关于使用 Mypy 的好处（这篇文章也被收入了