在 Spring ,我们维护了一个大型的 Python 单体代码库(英:monorepo),用上了 Mypy 最严格的配置项,实现了 Mypy 全覆盖。简而言之,这意味着每个函数签名都是带注解的,并且不允许有隐式的 Any
转换。
(译注:此处的 Spring 并不是 Java 中那个著名的 Spring 框架,而是一家生物科技公司,专注于找到与年龄相关的疾病的疗法,2022 年 3 月曾获得比尔&梅琳达·盖茨基金会 120 万美元的资助。)
诚然,代码行数是一个糟糕的衡量标准,但可作一个粗略的估计:我们的代码仓有超过 30 万行 Python 代码,其中大约一半构成了核心的数据平台,另一半是由数据科学家和机器学习研究员编写的终端用户代码。
我有个大胆的猜测,就这个规模而言,这是最全面的加了类型的 Python 代码仓之一。
我们在 2019 年 7 月首次引入了 Mypy,大约一年后实现了全面的类型覆盖,从此成为了快乐的 Mypy 用户。
几周前,我跟 Leo Boytsov 和 Erik Bernhardsson 在 Twitter 上对 Python 类型有一次简短的讨论——然后我看到 Will McGugan也对类型大加赞赏。由于 Mypy 是我们在 Spring 公司发布和迭代 Python 代码的关键部分,我想写一下我们在过去几年中大规模使用它的经验。
一句话总结:虽然采用 Mypy 是有代价的(前期和持续的投入、学习曲线等),但我发现它对于维护大型 Python 代码库有着不可估量的价值。Mymy 可能不适合于所有人,但它十分适合我。
Mypy 是什么?
(如果你很熟悉 Mypy,可跳过本节。)
Mypy 是 Python 的一个静态类型检查工具。如果你写过 Python 3,你可能会注意到 Python 支持类型注解,像这样:
def greeting(name: str) -> str:
return 'Hello ' + name
Python 在 2014 年通过 PEP-484 定义了这种类型注解语法。虽然这些注解是语言的一部分,但 Python(以及相关的第一方工具)实际上并不拿它们来强制做到类型安全。
相反,类型检查通过第三方工具来实现。Mypy 就是这样的工具。Facebook 的 ref="https://github.com/facebook/pyre-check">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 的目标之一是利用静态类型、不可变性等来提高性能——而且明确