“容器”这两个字很少被 Python 技术文章提起。一看到“容器”，大家想到的多是那头蓝色小鲸鱼：Docker，但这篇文章和它没有任何关系。本文里的容器，是 Python 中的一个抽象概念，是对专门用来装其他对象的数据类型的统称。

 

在 Python 中，有四类最常见的内建容器类型： 列表（list）、 元组（tuple）、 字典（dict）、 集合（set）。通过单独或是组合使用它们，可以高效的完成很多事情。

 

Python 语言自身的内部实现细节也与这些容器类型息息相关。比如 Python 的类实例属性、全局变量 globals（） 等就都是通过字典类型来存储的。

 

在这篇文章里，我首先会从容器类型的定义出发，尝试总结出一些日常编码的最佳实践。之后再围绕各个容器类型提供的特殊机能，分享一些编程的小技巧。

 

当我们谈论容器时，我们在谈些什么？

 

我在前面给了“容器”一个简单的定义：专门用来装其他对象的就是容器。但这个定义太宽泛了，无法对我们的日常编程产生什么指导价值。要真正掌握 Python 里的容器，需要分别从两个层面入手：

 

底层实现：内置容器类型使用了什么数据结构？某项操作如何工作？

 

高层抽象：什么决定了某个对象是不是容器？哪些行为定义了容器？

 

下面，让我们一起站在这两个不同的层面上，重新认识容器。

 

底层看容器

 

Python 是一门高级编程语言，它所提供的内置容器类型，都是经过高度封装和抽象后的结果。和“链表”、“红黑树”、“哈希表”这些名字相比，所有 Python 内建类型的名字，都只描述了这个类型的功能特点，其他人完全没法只通过这些名字了解它们的哪怕一丁点内部细节。

 

这是 Python 编程语言的优势之一。相比 C 语言这类更接近计算机底层的编程语言，Python 重新设计并实现了对编程者更友好的内置容器类型，屏蔽掉了内存管理等额外工作。为我们提供了更好的开发体验。

 

但如果这是 Python 语言的优势的话，为什么我们还要费劲去了解容器类型的实现细节呢？答案是：关注细节可以帮助我们编写出更快的代码。

 

写更快的代码

 

1. 避免频繁扩充列表/创建新列表

 

所有的内建容器类型都不限制容量。如果你愿意，你可以把递增的数字不断塞进一个空列表，最终撑爆整台机器的内存。

 

在 Python 语言的实现细节里，列表的内存是按需分配的[注1]，当某个列表当前拥有的内存不够时，便会触发内存扩容逻辑。而分配内存是一项昂贵的操作。虽然大部分情况下，它不会对你的程序性能产生什么严重的影响。但是当你处理的数据量特别大时，很容易因为内存分配拖累整个程序的性能。

 

还好，Python 早就意识到了这个问题，并提供了官方的问题解决指引，那就是：“变懒”。

 

如何解释“变懒”？ range（） 函数的进化是一个非常好的例子。

 

在 Python 2 中，如果你调用 range（100000000），需要等待好几秒才能拿到结果，因为它需要返回一个巨大的列表，花费了非常多的时间在内存分配与计算上。但在 Python 3 中，同样的调用马上就能拿到结果。因为函数返回的不再是列表，而是一个类型为 range 的懒惰对象，只有在你迭代它、或是对它进行切片时，它才会返回真正的数字给你。

 

所以说，为了提高性能，内建函数 range “变懒”了。而为了避免过于频繁的内存分配，在日常编码中，我们的函数同样也需要变懒，这包括：

 

更多的使用 yield 关键字，返回生成器对象

 

尽量使用生成器表达式替代列表推导表达式

 

生成器表达式： （iforinrange（100））

 

列表推导表达式： [iforinrange（100）]

 

尽量使用模块提供的懒惰对象：

 

使用 re.finditer 替代 re.findall

 

直接使用可迭代的文件对象： forlineinfp，而不是 forlineinfp.readlines（）

 

2. 在列表头部操作多的场景使用 deque 模块

 

列表是基于数组结构（Array）实现的，当你在列表的头部插入新成员（ list.insert（0,item））时，它后面的所有其他成员都需要被移动，操作的时间复杂度是 O（n）。这导致在列表的头部插入成员远比在尾部追加（ list.append（item） 时间复杂度为 O（1））要慢。

 

如果你的代码需要执行很多次这类操作，请考虑使用 collections.deque 类型来替代列表。因为 deque 是基于双端队列实现的，无论是在头部还是尾部追加元素，时间复杂度都是 O（1）。

 

3. 使用集合/字典来判断成员是否存在

 

当你需要判断成员是否存在于某个容器时，用集合比列表更合适。因为 itemin[…] 操作的时间复杂度是 O（n），而 itemin{…} 的时间复杂度是 O（1）。这是因为字典与集合都是基于哈希表（Hash Table）数据结构实现的。

 

Hint: 强烈建议阅读 TimeComplexity - Python Wiki，了解更多关于常见容器类型的时间复杂度相关内容。

 

如果你对字典的实现细节感兴趣，也强烈建议观看 Raymond Hettinger 的演讲 Modern Dictionaries（YouTube）

 

高层看容器

 

Python 是一门“鸭子类型”语言：“当看到一只鸟走起来像鸭子、游泳起来像鸭子、叫起来也像鸭子，那么这只鸟就可以被称为鸭子。”所以，当我们说某个对象是什么类型时，在根本上其实指的是：这个对象满足了该类型的特定接口规范，可以被当成这个类型来使用。而对于所有内置容器类型来说，同样如此。

 

打开位于 collections 模块下的 abc（“抽象类 Abstract Base Classes”的首字母缩写）子模块，可以找到所有与容器相关的接口（抽象类）[注2]定义。让我们分别看看那些内建容器类型都满足了什么接口：

 

列表（list）：满足 Iterable、 Sequence、 MutableSequence 等接口

 

元组（tuple）：满足 Iterable、 Sequence

 

字典（dict）：满足 Iterable、 Mapping、 MutableMapping [注3]

 

集合（set）：满足 Iterable、 Set、 MutableSet [注4]

 

每个内置容器类型，其实就是满足了多个接口定义的组合实体。比如所有的容器类型都满足 “可被迭代的”（Iterable） 这个接口，这意味着它们都是“可被迭代”的。但是反过来，不是所有“可被迭代”的对象都是容器。就像字符串虽然可以被迭代，但我们通常不会把它当做“容器”来看待。

 

了解这个事实后，我们将在 Python 里重新认识面向对象编程中最重要的原则之一：面向接口而非具体实现来编程。

 

让我们通过一个例子，看看如何理解 Python 里的“面向接口编程”。

 

写扩展性更好的代码

 

某日，我们接到一个需求：有一个列表，里面装着很多用户评论，为了在页面正常展示，需要将所有超过一定长度的评论用省略号替代。

 

这个需求很好做，很快我们就写出了第一个版本的代码：

 

上面的代码里， add_ellipsis 函数接收一个列表作为参数，然后遍历它，替换掉需要修改的成员。这一切看上去很合理，因为我们接到的最原始需求就是：“有一个 列表，里面…”。但如果有一天，我们拿到的评论不再是被继续装在列表里，而是在不可变的元组里呢？

 

那样的话，现有的函数设计就会逼迫我们写出 add_ellipsis（list（comments）） 这种即慢又难看的代码了。

 

面向容器接口编程

 

我们需要改进函数来避免这个问题。因为 add_ellipsis 函数强依赖了列表类型，所以当参数类型变为元组时，现在的函数就不再适用了（原因：给 comments[index] 赋值的地方会抛出 TypeError 异常）。如何改善这部分的设计？秘诀就是：让函数依赖“可迭代对象”这个抽象概念，而非实体列表类型。

 

使用生成器特性，函数可以被改成这样：

 

在新函数里，我们将依赖的参数类型从列表改成了可迭代的抽象类。这样做有很多好处，一个最明显的就是：无论评论是来自列表、元组或是某个文件，新函数都可以轻松满足：

 

将依赖由某个具体的容器类型改为抽象接口后，函数的适用面变得更广了。除此之外，新函数在执行效率等方面也都更有优势。现在让我们再回到之前的问题。从高层来看，什么定义了容器？

 

答案是：各个容器类型实现的接口协议定义了容器。不同的容器类型在我们的眼里，应该是 是否可以迭代、 是否可以修改、 有没有长度 等各种特性的组合。我们需要在编写相关代码时，更多的关注容器的抽象属性，而非容器类型本身，这样可以帮助我们写出更优雅、扩展性更好的代码。

 

Hint：在 itertools 内置模块里可以找到更多关于处理可迭代对象的宝藏。

 

常用技巧

 

1. 使用元组改善分支代码

 

有时，我们的代码里会出现超过三个分支的 if/else 。就像下面这样：

 

上面这个函数挑不出太多毛病，很多很多人都会写出类似的代码。但是，如果你仔细观察它，可以在分支代码部分找到一些明显的“边界”。比如，当函数判断某个时间是否应该用“秒数”展示时，用到了 60。而判断是否应该用分钟时，用到了 3600。

 

从边界提炼规律是优化这段代码的关键。如果我们将所有的这些边界放在一个有序元组中，然后配合二分查找模块 bisect。整个函数的控制流就能被大大简化：

 

除了用元组可以优化过多的 if/else 分支外，有些情况下字典也能被用来做同样的事情。关键在于从现有代码找到重复的逻辑与规律，并多多尝试。