Python容器使用的5个技巧和2个误区总结
Python容器使用的5个技巧和2个误区
“容器”这两个字很少被Python技术文章提起。一看到“容器”，大家想到的多是那头蓝色小鲸鱼：Docker，但这篇文章和它没有任何关系。本文里的容器，是Python中的一个抽象概念，是对专门用来装其他对象的数据类型的统称。
在Python中，有四类最常见的内建容器类型：列表（list）、元组（tuple）、字典（dict）、集合（set）。通过单独或是组合使用它们，可以高效的完成很多事情。
Python语言自身的内部实现细节也与这些容器类型息息相关。比如Python的类实例属性、全局变量globals()等就都是通过字典类型来存储的。
在这篇文章里，我首先会从容器类型的定义出发，尝试总结出一些日常编码的最佳实践。之后再围绕各个容器类型提供的特殊机能，分享一些编程的小技巧。
当我们谈论容器时，我们在谈些什么？
我在前面给了“容器”一个简单的定义：专门用来装其他对象的就是容器。但这个定义太宽泛了，无法对我们的日常编程产生什么指导价值。要真正掌握Python里的容器，需要分别从两个层面入手：
·底层实现：内置容器类型使用了什么数据结构？某项操作如何工作？
·高层抽象：什么决定了某个对象是不是容器？哪些行为定义了容器？
下面，让我们一起站在这两个不同的层面上，重新认识容器。
底层看容器
Python是一门高级编程语言，它所提供的内置容器类型，都是经过高度封装和抽象后的结果。和“链表”、“红黑树”、“哈希表”这些名字相比，所有Python内建类型的名字，都只描述了这个类型的功能特点，其他人完全没法只通过这些名字了解它们的哪怕一丁点内部细节。
这是Python编程语言的优势之一。相比C语言这类更接近计算机底层的编程语言，Python重新设计并实现了对编程者更友好的内置容器类型，屏蔽掉了内存管理等额外工作。为我们提供了更好的开发体验。
但如果这是Python语言的优势的话，为什么我们还要费劲去了解容器类型的实现细节呢？答案是：关注细节可以帮助我们编写出更快的代码。
写更快的代码
1.避免频繁扩充列表/创建新列表
所有的内建容器类型都不限制容量。如果你愿意，你可以把递增的数字不断塞进一个空列表，最终撑爆整台机器的内存。
在Python语言的实现细节里，列表的内存是按需分配的[注1]，当某个列表当前拥有的内存不够时，便会触发内存扩容逻辑。而分配内存是一项昂贵的操作。虽然大部分情况下，它不会对你的程序性能产生什么严重的影响。但是当你处理的数据量特别大时，很容易因为内存分配拖累整个程序的性能。
还好，Python早就意识到了这个问题，并提供了官方的问题解决指引，那就是：“变懒”。
如何解释“变懒”？range()函数的进化是一个非常好的例子。
在Python2中，如果你调用range(100000000)，需要等待好几秒才能拿到结果，因为它需要返回一个巨大的列表，花费了非常多的时间在内存分配与计算上。但在Python3中，同样的调用马上就能拿到结果。因为函数返回的不再是列表，而是一个类型为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)。这是因为字典与集合都是基于哈希表（HashTable）数据结构实现的。
#这个例子不是特别恰当，因为当目标集合特别小时，使用集合还是列表对效率的影响微乎其微
#但这不是重点:)
VALID_NAMES=["piglei","raymond","bojack","caroline"]
#转换为集合类型专门用于成员判断
VALID_NAMES_SET=set(VALID_NAMES)
defvalidate_name(name):
ifnamenotinVALID_NAMES_SET:
#此处使用了Python3.6添加的f-strings特性
raiseValueError(f"{name}isnotavalidname!")
Hint:强烈建议阅读TimeComplexity-PythonWiki，了解更多关于常见容器类型的时间复杂度相关内容。
如果你对字典的实现细节感兴趣，也强烈建议观看RaymondHettinger的演讲ModernDictionaries(YouTube)
高层看容器
Python是一门“鸭子类型”语言：“当看到一只鸟走起来像鸭子、游泳起来像鸭子、叫起来也像鸭子，那么这只鸟就可以被称为鸭子。”所以，当我们说某个对象是什么类型时，在根本上其实指的是：这个对象满足了该类型的特定接口规范，可以被当成这个类型来使用。而对于所有内置容器类型来说，同样如此。
打开位于collections模块下的abc（“抽象类AbstractBaseClasses”的首字母缩写）子模块，可以找到所有与容器相关的接口（抽象类）[注2]定义。让我们分别看看那些内建容器类型都满足了什么接口：
·列表（list）：满足Iterable、Sequence、MutableSequence等接口
·元组（tuple）：满足Iterable、Sequence
·字典（dict）：满足Iterable、Mapping、MutableMapping[注3]
·集合（set）：满足Iterable、Set、MutableSet[注4]
每个内置容器类型，其实就是满足了多个接口定义的组合实体。比如所有的容器类型都满足“可被迭代的”（Iterable）这个接口，这意味着它们都是“可被迭代”的。但是反过来，不是所有“可被迭代”的对象都是容器。就像字符串虽然可以被迭代，但我们通常不会把它当做“容器”来看待。
了解这个事实后，我们将在Python里重新认识面向对象编程中最重要的原则之一：面向接口而非具体实现来编程。
让我们通过一个例子，看看如何理解Python里的“面向接口编程”。
写扩展性更好的代码
某日，我们接到一个需求：有一个列表，里面装着很多用户评论，为了在页面正常展示，需要将所有超过一定长度的评论用省略号替代。
这个需求很好做，很快我们就写出了第一个版本的代码：
#注：为了加强示例代码的说明性，本文中的部分代码片段使用了Python3.5
#版本添加的TypeHinting特性
defadd_ellipsis(comments:typing.List[str],max_length:int=12):
"""如果评论列表里的内容超过max_length，剩下的字符用省略号代替
"""
index=0
forcommentincomments:
comment=comment.strip()
iflen(comment)>max_length:
comments[index]=comment[:max_length]+'...'
index+=1
returncomments
comments=[
"Implementationnote",
"Changed",
"ABCforgenerator",
]
print("\n".join(add_ellipsis(comments)))
#OUTPUT:
#Implementati...
#Changed
#ABCforgene...
上面的代码里，add_ellipsis函数接收一个列表作为参数，然后遍历它，替换掉需要修改的成员。这一切看上去很合理，因为我们接到的最原始需求就是：“有一个列表，里面...”。但如果有一天，我们拿到的评论不再是被继续装在列表里，而是在不可变的元组里呢？
那样的话，现有的函数设计就会逼迫我们写出add_ellipsis(list(comments))这种即慢又难看的代码了。
面向容器接口编程
我们需要改进函数来避免这个问题。因为add_ellipsis函数强依赖了列表类型，所以当参数类型变为元组时，现在的函数就不再适用了（原因：给comments[index]赋值的地方会抛出TypeError异常）。如何改善这部分的设计？秘诀就是：让函数依赖“可迭代对象”这个抽象概念，而非实体列表类型。
使用生成器特性，函数可以被改成这样：
defadd_ellipsis_gen(comments:typing.Iterable[str],max_length:int=12):
"""如果可迭代评论里的内容超过max_length，剩下的字符用省略号代替
"""
forcommentincomments:
comment=comment.strip()
iflen(comment)>max_length:
yieldcomment[:max_length]+'...'
else:
yieldcomment
print("\n".join(add_ellipsis_gen(comments)))
在新函数里，我们将依赖的参数类型从列表改成了可迭代的抽象类。这样做有很多好处，一个最明显的就是：无论评论是来自列表、元组或是某个文件，新函数都可以轻松满足
#处理放在元组里的评论
comments=("Implementationnote","Changed","ABCforgenerator")
print("\n".join(add_ellipsis_gen(comments)))
#处理放在文件里的评论
withopen("comments")asfp:
forcommentinadd_ellipsis_gen(fp):
print(comment)
将依赖由某个具体的容器类型改为抽象接口后，函数的适用面变得更广了。除此之外，新函数在执行效率等方面也都更有优势。现在让我们再回到之前的问题。从高层来看，什么定义了容器？
答案是：各个容器类型实现的接口协议定义了容器。不同的容器类型在我们的眼里，应该是是否可以迭代、是否可以修改、有没有长度等各种特性的组合。我们需要在编写相关代码时，更多的关注容器的抽象属性，而非容器类型本身，这样可以帮助我们写出更优雅、扩展性更好的代码。
Hint：在itertools内置模块里可以找到更多关于处理可迭代对象的宝藏。
常用技巧
1.使用元组改善分支代码
有时，我们的代码里会出现超过三个分支的if/else。就像下面这样：
importtime
deffrom_now(ts):
"""接收一个过去的时间戳，返回距离当前时间的相对时间文字描述
"""
now=time.time()
seconds_delta=int(now-ts)
ifseconds_delta<1:
return"lessthan1secondago"
elifseconds_delta<60:
return"{}secondsago".format(seconds_delta)
elifseconds_delta<3600:
return"{}minutesago".format(seconds_delta//60)
elifseconds_delta<3600*24:
return"{}hoursago".format(seconds_delta//3600)
else:
return"{}daysago".format(seconds_delta//(3600*24))
now=time.time()
print(from_now(now))
print(from_now(now-24))
print(from_now(now-600))
print(from_now(now-7500))
print(from_now(now-87500))
#OUTPUT:
#lessthan1secondago
#24secondsago
#10minutesago
#2hoursago
#1daysago
上面这个函数挑不出太多毛病，很多很多人都会写出类似的代码。但是，如果你仔细观察它，可以在分支代码部分找到一些明显的“边界”。比如，当函数判断某个时间是否应该用“秒数”展示时，用到了60。而判断是否应该用分钟时，用到了3600。
从边界提炼规律是优化这段代码的关键。如果我们将所有的这些边界放在一个有序元组中，然后配合二分查找模块bisect。整个函数的控制流就能被大大简化：
importbisect
#BREAKPOINTS必须是已经排好序的，不然无法进行二分查找
BREAKPOINTS=(1,60,3600,3600*24)
TMPLS=(
#unit,template
(1,"lessthan1secondago"),
(1,"{units}secondsago"),
(60,"{units}minutesago"),
(3600,"{units}hoursago"),
(3600*24,"{units}daysago"),
)
deffrom_now(ts):
"""接收一个过去的时间戳，返回距离当前时间的相对时间文字描述
"""
seconds_delta=int(time.time()-ts)
unit,tmpl=TMPLS[bisect.bisect(BREAKPOINTS,seconds_delta)]
returntmpl.format(units=seconds_delta//unit)
除了用元组可以优化过多的if/else分支外，有些情况下字典也能被用来做同样的事情。关键在于从现有代码找到重复的逻辑与规律，并多多尝试。
2.在更多地方使用动态解包
动态解包操作是指使用*或**运算符将可迭代对象“解开”的行为，在Python2时代，这个操作只能被用在函数参数部分，并且对出现顺序和数量都有非常严格的要求，使用场景非常单一。
defcalc(a,b,multiplier=1):
return(a+b)*multiplier
#Python2中只支持在函数参数部分进行动态解包
printcalc(*[1,2],**{"multiplier":10})
#OUTPUT:30
不过，Python3尤其是3.5版本后，*和**的使用场景被大大扩充了。举个例子，在Python2中，如果我们需要合并两个字典，需要这么做：
defmerge_dict(d1,d2):
#因为字典是可被修改的对象，为了避免修改原对象，此处需要复制一个d1的浅拷贝
result=d1.copy()
result.update(d2)
returnresult
user=merge_dict({"name":"piglei"},{"movies":["FightClub"]})
但是在Python3.5以后的版本，你可以直接用**运算符来快速完成字典的合并操作：
user={**{"name":"piglei"},**{"movies":["FightClub"]}}
除此之外，你还可以在普通赋值语句中使用*运算符来动态的解包可迭代对象。如果你想详细了解相关内容，可以阅读下面推荐的PEP。
Hint：推进动态解包场景扩充的两个PEP：
·PEP3132--ExtendedIterableUnpacking|Python.org
·PEP448--AdditionalUnpackingGeneralizations|Python.org
3.最好不用“获取许可”，也无需“要求原谅”
这个小标题可能会稍微让人有点懵，让我来简短的解释一下：“获取许可”与“要求原谅”是两种不同的编程风格。如果用一个经典的需求：“计算列表内各个元素出现的次数”来作为例子，两种不同风格的代码会是这样：
#AF:AskforForgiveness
#要做就做，如果抛出异常了，再处理异常
defcounter_af(l):
result={}
forkeyinl:
try:
result[key]+=1
exceptKeyError:
result[key]=1
returnresult
#AP:AskforPermission
#做之前，先问问能不能做，可以做再做
defcounter_ap(l):
result={}
forkeyinl:
ifkeyinresult:
result[key]+=1
else:
result[key]=1
returnresult
整个Python社区对第一种AskforForgiveness的异常捕获式编程风格有着明显的偏爱。这其中有很多原因，首先，在Python中抛出异常是一个很轻量的操作。其次，第一种做法在性能上也要优于第二种，因为它不用在每次循环的时候都做一次额外的成员检查。
不过，示例里的两段代码在现实世界中都非常少见。为什么？因为如果你想统计次数的话，直接用collections.defaultdict就可以了：
fromcollectionsimportdefaultdict defcounter_by_collections(l): result=defaultdict(int) forkeyinl: result[key]+=1 returnresult
这样的代码既不用“获取许可”，也无需“请求原谅”。整个代码的控制流变得更清晰自然了。所以，如果可能的话，请尽量想办法省略掉那些非核心的异常捕获逻辑。一些小提示：
·操作字典成员时：使用collections.defaultdict类型
·或者使用dict[key]=dict.setdefault(key,0)+1内建函数
·如果移除字典成员，不关心是否存在：
·调用pop函数时设置默认值，比如dict.pop(key,None)
·在字典获取成员时指定默认值：dict.get(key,default_value)
·对列表进行不存在的切片访问不会抛出IndexError异常：["foo"][100:200]
4.使用next()函数
next()是一个非常实用的内建函数，它接收一个迭代器作为参数，然后返回该迭代器的下一个元素。使用它配合生成器表达式，可以高效的实现“从列表中查找第一个满足条件的成员”之类的需求。
numbers=[3,7,8,2,21] #获取并**立即返回**列表里的第一个偶数 print(next(iforiinnumbersifi%2==0)) #OUTPUT:8
5.使用有序字典来去重
字典和集合的结构特点保证了它们的成员不会重复，所以它们经常被用来去重。但是，使用它们俩去重后的结果会丢失原有列表的顺序。这是由底层数据结构“哈希表（HashTable）”的特点决定的。
>>>l=[10,2,3,21,10,3]
#去重但是丢失了顺序
>>>set(l)
{3,10,2,21}
如果既需要去重又必须保留顺序怎么办？我们可以使用collections.OrderedDict模块：
Hint:在Python3.6中，默认的字典类型修改了实现方式，已经变成有序的了。并且在Python3.7中，该功能已经从语言的实现细节变成了为可依赖的正式语言特性。
但是我觉得让整个Python社区习惯这一点还需要一些时间，毕竟目前“字典是无序的”还是被印在无数本Python书上。所以，我仍然建议在一切需要有序字典的地方使用OrderedDict。
常见误区
1.当心那些已经枯竭的迭代器
在文章前面，我们提到了使用“懒惰”生成器的种种好处。但是，所有事物都有它的两面性。生成器的最大的缺点之一就是：它会枯竭。当你完整遍历过它们后，之后的重复遍历就不能拿到任何新内容了。
numbers=[1,2,3] numbers=(i*2foriinnumbers) #第一次循环会输出2,4,6 fornumberinnumbers: print(number) #这次循环什么都不会输出，因为迭代器已经枯竭了 fornumberinnumbers: print(number)
而且不光是生成器表达式，Python3里的map、filter内建函数也都有一样的特点。忽视这个特点很容易导致代码中出现一些难以察觉的Bug。
Instagram就在项目从Python2到Python3的迁移过程中碰到了这个问题。它们在PyCon2017上分享了对付这个问题的故事。访问文章Instagram在PyCon2017的演讲摘要，搜索“迭代器”可以查看详细内容。
2.别在循环体内修改被迭代对象
这是一个很多Python初学者会犯的错误。比如，我们需要一个函数来删掉列表里的所有偶数：
defremove_even(numbers): """去掉列表里所有的偶数 """ fori,numberinenumerate(numbers): ifnumber%2==0: #有问题的代码 delnumbers[i] numbers=[1,2,7,4,8,11] remove_even(numbers) print(numbers) #OUTPUT:[1,7,8,11]
注意到结果里那个多出来的“8”了吗？当你在遍历一个列表的同时修改它，就会出现这样的事情。因为被迭代的对象numbers在循环过程中被修改了。遍历的下标在不断增长，而列表本身的长度同时又在不断缩减。这样就会导致列表里的一些成员其实根本就没有被遍历到。
所以对于这类操作，请使用一个新的空列表保存结果，或者利用yield返回一个生成器。而不是修改被迭代的列表或是字典对象本身。
以上就是Python容器使用的5个技巧和2个误区的详细内容，更多请关注毛票票其它相关文章！