引言

本文介绍我在 PyCon2020 年底时分享的议题内容，结尾有 录播的视频 和 PPT下载链接 。

Python强类型检查的历史、背景

Pyton 语言与类型限定

我们都知道Python是一门 强类型的动态类型 语言，具体如下特性：

可以动态构造脚本执行、修改函数、对象类型结构、变量类型
但不允许类型不匹配的操作

这里举了2个例子，第一个例子体现 动态性 ：用字符串直接执行代码，动态构建了一个函数并执行，甚至给函数挂载新的名字。第二个例子体现 强类型性 ：变量都有类型信息，不同类型无适配操作时不允许操作，例如整数和字符串不允许相加。

动态语言 vs 类型提示

因为Python的强类型挂载，但是又不像C++/Java有强类型定义信息（C++11开始也有auto自动推导了），比较容易出错。因此Python也提供了 类型标注 功能，有了类型标注提示后，就可以在 编码时 即发现错误。

例如下面一个有标注，一个没有标注的例子；可以看到有标注的例子，IDE/工具都会在编码时即发现潜在与标注不匹配的 执行甚至逻辑 错误并提示，而无标注时，工具的支持就大打折扣了。

函数标注（ PEP 3107 ）

标注功能是通过PEP 3107就添加进来了，以函数的标注为例，实际上对函数参数、返回值标注，是放在 add. __annotations__ 变量里面。如图，IDE、工具可以在代码层面静态检查并提示错误，信息非常直观。

强类型检查的优势与现状

通过上面的例子就可以发现，强类型检查可以给Python带来不少好处，这方面总结的文章不少，这里总结一下如下：

易读：比docstring更易理解接口协议，也更易使用三方库（IDE工具支持）
排错：编码、编译期间即可发现错误（IDE工具支持）。
重构：接口范围明确，更易于理解和放心重构。
性能：（可能）可以做到静态编译优化。

那么 实际落地 的情况如何呢？可以看到还是乐观的：

生态-IDE：三方类型检查工具比较全面（PyCharm、VSCode、VIM等）。
生态-库工具：三方库有官方或大厂支持且很流行。

- 官方/mypy-9.5K star、Facebook/pyre-5K Star，Google/pytype-3K star等。

成熟度：静态检查已被广泛验证有效性，尤其大型工程（ dropbox迁移400万行到静态标注）。
行业：主流编程语言以静态强类型检查为主（C++、Java、Go等）；其他动态语言的静态类型扩展迅猛发展（如TypeScript）。

Python 强类型检查的策略

既然强类型有这么多好处，并且已经越来越被接受，是不是意味着Python会往强类型语言转型呢？

可以确认不会发生（至少在Python3上），因为Guido很早就在正式文档中阐述了这方面的策略：

Python will remain a dynamically typed language , and the authors have no desire to ever make type hints mandatory, even by convention.
——Guido in PEP 484

可以看到Python的策略是 保留了类型检查向后兼容的能力 ，不会转型为真正的强类型检查语言，但是Python依然会对强类型检查做持续的支持，通过如下金字塔结构来完成，最终达到即享受强类型检查的好处，又保持向后兼容和动态类型语言的灵活性，根据后续的介绍，可以看到，这方面Python还是付出了不少的努力。

Python 类型系统到 Py3.7 （ 2018.6 ）才基本成型

具体来看下Python做了哪些事情来支持强类型检查，如下是一个非常长的（14个）PEP（Python改进建议）的列表和落地情况（图中时间是文档时间+1年左右是实际落地时间），可以看到2006年Python就引入了一些基础支持，并且在PEP 483开始快速迭代（图中橙色是比较重要的迭代），并且到了Python3.7才真正算是成型。

Python强类型检查常用场景实践（22个）

下面开始浏览一下Python强类型检查的能力在各个主要场景下的具体最佳实践

典型类型标注

场景1：复杂数据结构的标注（使用别名）（PEP 484）

当被标注的类型比较复杂时，可以使用 类型别名 来简化类型提示标注。（这里直接使用了内置类型[]做标注（PEP 585））

这个例子中servers是一个比较复杂的结构，它的每个成员可以用一个变量（别名）接住后再继续定义，最后用于标注。

场景2：变参类型标注（PEP 484）

Python的变参也支持标注，如下案例解释了如何对变参、命名变参直接标注其值的类型：

场景3：类别选择 Union vs. TypeVar（PEP 484）

Python的动态灵活性，允许一个变量的类型可以是多个选择（例如一个add函数允许传入int、long、str类型的变量等），在这种情况下可以Union和TypeVar来定义。两者区别如下：

使用Union定义可能的类型选择： x、y、返回值的类型同一时刻可以不同
使用TypeVar定义一组类型：x、y、返回值的类型同一时刻必须相同

以下举例说明了两者区别：

场景4：函数类型（PEP 484）

高阶函数可以接收或返回函数，因此函数和变量一样，也需要类型标注，具体形式可以如下：

Callable[[参数 1 类型 , 参数 2 类型 , …], 返回类型]

例如下面这个高阶函数的参数标注：

场景5：泛型类型（PEP 484）

容器下的泛型：TypeVar

泛型在C++/Java中非常普通，Python中也存在这样的情况，例如参数需要是一个列表，但是里面元素类型可以不定。这种情况，可以使用泛型 TypeVar 。例如下面这个函数接受一个泛型列表，并返回第一个元素。在标注后，错误的使用情况也可以被检查出来。

当泛型是多个可选类型时，TypeVar也支持，如下例子：

类下的泛型：Generic

泛型场景比较丰富，类也有泛化需求，例如一个类需要定义泛型时，比较好的方式是，使用Generic并继承它，参考如下案例：

以上就各种情况的标注做了大概的介绍，可以看到Python对各种类型的标注都可以很好支持，下面具体讲解一下标注的方式。

标注方式

场景6：使用注释（Comments）进行标注（Annotation）（PEP 484）

可以看到，目前为止的标注都是以 修改代码 才能完成的，这样某种程度上是有一定风险的，因为修改了代码，就意味着可能引入了BUG，哪怕风险不高。这个问题实际PEP已经考虑到了，这并不是Python添加强类型检查的唯一方式。

除了上面的代码方式标注，还可以用注释进行标注。

形式如下：

# type: xxxx 进行标注
注意其中函数的标注方式：

- ( 参数类型列表 ) -> 返回值类型

这里举一个例子说明：

场景7：将标注放在单独文件（PEP 484)

添加注释某种程度上不算修改源码，但还是会修改源代码文件（依然引入了一些风险，并且可能源代码不一定有权限去添加注释），因此PEP 484还引入独立的文件方式来解决这个问题：

具体的方法是，使用一个独立的Stub文件（.pyi）与源文件相同，并放在同一个文件夹即可。而Pyi的语法是将源文件的一些类、函数、变量等都打上标注（不需要具体实现）。

例如：

这样的方法有优点也有缺点：

优点：

- 不需要修改源代码（减少引入BUG可能）
- Pyi可以使用最新的语法（源文件可以是低版本）
- 测试友好
- 不拥有的三方库，也可以补充标注信息。

缺点：

- 代码重复写了一遍头（工作量）
- 打包变得复杂

高级类型标注

场景8：前置引用（PEP 484）

强类型检查实际是是非常复杂的（参考C++模板技术与泛型编程），在进行类型标注时，实际的扩展的情况要复杂的多，下面开始讲解一些高阶的强类型标注的场景。

首先看一个经典案例是一个二叉树节点，在进行类型标注是，就需要引用自己，改如何解决？

这种情况下就需要使用 前置引用 ，方式是用 字符串 代替类型标注。参考下面例子：

场景9：函数标注扩展overload（PEP 484）

我们都知道Python函数语法本身不支持重载（实际通过库可以扩展），一般一个函数可以接受各种情况的参数，并返回特定的类型。例如一个add，传递int就返回int，传递bytes/str就返回str，这种情况下应该如何标注呢？

可以使用 typing. overload 进行参数返回值描述。参考下面的案例，但需要注意：

必须有一个无修饰版本做真正实现。
这里仅仅用于静态类型检查，如果需要真正的重载，可以使用 functools.singleddispatch 等

有时可以用TypeVar代替，显得更简洁，但请注意和上述 overload 有一个重要区别，就是入参与返回参数的映射关系丢失了。

场景10：协变(covariant)与逆变(contravariant) PEP 484

在泛型编程中，还有一个比较常见的概念就是协变与逆变（Java泛型编程中常常遇到），如下定义：

协变：

- 让一个粗粒度接口（或委托）可以接收一个更加具体的接口（或委托）作为参数（或返回值）；
- 例如：老鹰列表赋值给鸟列表

逆变：

- 让一个接口（或委托）的参数类型（或返回值）类型更加具体化，也就是参数类型更强，更明确。
- 例如：鸟列表赋值给老鹰列表

这种情况在Python强类型标注也一样存在，例如下面是一个协变的例子，注意使用了参数 covariant=True ：

场景11：静态duck typing（PEP 544）

Python支持OOP，也支持duck typing，在强类型检查中，duck typing也一样适用，例如一个函数 close_resource 接受一个参数，要求这个参数必须提供一个特定的方法.close()。这种需求在强类型检查时，也可以支持，我们称之为 静态duck typing ，相关方案由PEP 544支持。

如下是一个具体案例：

通过继承typing.Protocol，构建了一个IResource的静态类型，再使用这个IResource进行标注，之后就可以实现对所有参数是否具备这个IResource定义的方法进行校验。这就是static duck typing。

某种程度上，可以静态duck typing类似于Java的接口概念。

可以有实现，可以被继承
可以继承多个接口，构建一个新接口（参考后面的例子）

但实际类型检查时，不要求被标注对象继承这个IResource，只需要对象的所有成员方法signature匹配Protocol即可。

如下是一个多继承的例子：

场景12：泛型静态duck typing（PEP 544）

通用的，泛化在静态duck typing也存在，例如约束的方法中的某个参数的类型，需要是泛化的。这种情况，typing.Protocol也是支持。

和前面一样，只需要使用TypeVar定义个泛型类型，再传递给Protocol即可。参考下面样例，这里定义了一个 标准可迭代对象 的泛型静态duck typing。

同样的，也支持泛型编程中的协变或逆变:

场景13：运行时化duck typing（PEP 544）

静态duck typing，顾名思义，静态时（编码时）检查，运行时不检查。但有时，也存在运行时使用isinstance检查的需求，这种情况下，这种需求也是支持。只需要使用runtime_checkable装饰，即可让Protocol可以运行时访问，例如isinstance检查。

参考如下例子：

有用的标注库

场景14：dataclasses（PEP 557）

Python对强类型编程的支持不限于标注类型的支持，也提供了许多基于强类型标注上结合Python自身灵活性扩展的非常强大库来增加工程效率，这里我们介绍一个相关的非常有用的库dataclasses。

这个库顾名思义，支持数据类的快速构建，可以把dataclass理解为一个加强版的namedtuple，是一个支持带默认值的可变的命名元祖：

甚至还支持延迟初始化，如下的变量c是基于a和b的值，动态初始化的。

也支持复杂的默认值，例如下面的mylist不传入时，会使用空list初始化。

dataclasss也提供了与tuple、dict互转方法，如下：

场景15：字面量类型（PEP 586）

Python较新的发布，继续发挥其灵活性的特点，不限于借鉴其他语言的强类型机制，还发扬光大，添加许多更灵活有用的功能，例如这个字面量类型。

有了这个功能后，可以做到不修改类型为enum的情况下，限定传递参数。

语法形式： Literal[ 字面量 1, 字面量 2, …]

例如下面例子，使用Literal，限定了打开文件的mode字符串的可枚举值，编码期间就可以检查非法的参数：

场景16：typing.Final（PEP 591）

通用的，在Python 3.8版本中引入一个扩展的标注typeing.Final，用于标注变量，这个内置标注非常有用，可以理解为实现了C++语法const的静态检查作用。

指定变量被初始化后无法再被修改、类变量无法被子类修改。
声明为Final的类成员的变量，未初始化的，必须在__init__里面初始化。

如下案例具体说明：

场景17：typing.final（PEP 591）

另一个被引入的就是小写的typing.final，用于标注类，可以理解为实现了Java语法final的静态检查作用。虽然Python本身就可以扩展实现运行时final的作用，但是这里实现了检查期的final，这个官方版本可以说非常的有用。

如下，除了可以修饰类（不能被继承），甚至可以修饰类的方法（ 不能被重写 ）。

优化、控制与扩展

场景18：延迟类型提示执行（PEP 563）

我们知道，Python标注执行期间不做强类型检查，但实际上标注依然会占用资源（空间和时间），下面开始我们看一些性能优化的场景。

例如下面的是一个极端例子，标注初始化指向了一些代码逻辑，初始化时，需要额外的资源消耗。

为了优化，可以开启 延迟类型提示执行 ，只需要从 __future__ 导入 annotations 即可，这时会跳过标注的代码逻辑，直接转化为字符串。

参考下面案例：

场景19：静态检查时与运行时区分（PEP 484）

可以看到类型检查需要导入一些库，也就增加了运行时的开销，因此Python引入 检查时 的概念，允许在检查时才导入特定库，而在实际运行时不导入。但是注意这种情况下，相关标注只能用注释或字符串（前置）方式标注。

例如下面的例子，可以即保持静态检查，又不会因为引入特定标注库对性能和资源产生冲击：

场景20：关闭静态类型检查（PEP 484）

特定情况下，我们也需要关闭静态检查（例如测试或开发中间时），这种情况只需要使用 typing. no_type_check 修饰函数或类来关闭。但是如果希望关闭对一个装饰器的静态检查的话，需要使用 typing. no_type_check_decorator 修饰装饰器来关闭。