十二个坑爹的Python陷阱

我我的对陷阱的定义是这样的：代码看起来能够工做，但不是以你“想固然“”的方式。若是一段代码直接出错，抛出了异常，我不认为这是陷阱。好比，Python程序员应该都遇到过的“UnboundLocalError”, 示例：

对于“UnboundLocalError”,还有更高级的版本：

可能对于不少python新手来讲，这个Error让人摸不着头脑。但我认为这不算陷阱，由于这段代码必定会报错，而不是默默的以错误的方式运行。不怕真小人，就怕伪君子。我认为缺陷就比如伪君子。

那么Python中哪些真正算得上陷阱呢

第一：以mutable对象做为默认参数

这个估计是最广为人知的了，Python和其余不少语言同样，提供了默认参数，默认参数确实是个好东西，可让函数调用者忽略一些细节（好比GUI编程，Tkinter，QT），对于lambda表达式也很是有用。可是若是使用了可变对象做为默认参数，那么事情就不那么愉快了

惊喜不惊喜？！究其缘由，python中一切都是对象，函数也不列外，默认参数只是函数的一个属性。而默认参数在函数定义的时候已经求值了。

Default parameter values are evaluated when the function definition is executed.

stackoverflow上有一个更适当的例子来讲明默认参数是在定义的时候求值，而不是调用的时候。

python docoment 给出了标准的解决办法：

A way around this is to use None as the default, and explicitly test for it in the body of the function

第二: x += y vs x = x + y

通常来讲，两者是等价的，至少看起来是等价的（这也是陷阱的定义 — 看起来都OK，但不必定正确）。

呃，被光速打脸了？

前者x指向一个新的对象，后者x在原来的对象是修改，固然，那种效果是正确的取决于应用场景。至少，得知道，两者有时候并不同

第三，神奇的小括号—()

小括号（parenthese）在各类编程语言中都有普遍的应用，python中，小括号还能表示元组（tuple）这一数据类型, 元组是immutable的序列。

但若是只有一个元素呢

神奇不神奇，若是要表示只有一个元素的元组，正确的姿式是:

第四：生成一个元素是列表的列表

这个有点像二维数组，固然生成一个元素是字典的列表也是能够的，更通俗的说，生成一个元素是可变对象的序列

很简单嘛：

看起来很不错，简单明了，but

我猜，这应该不是你预期的结果吧，究其缘由，仍是由于python中list是可变对象，上述的写法你们都指向的同一个可变对象，正确的姿式

另一个在实际编码中遇到的问题，dict.fromkeys, 也有殊途同归之妙： 建立的dict的全部values指向同一个对象。

fromkeys(seq[, value])
复制代码

Create a new dictionary with keys from seq and values set to value.

第五，在访问列表的时候，修改列表

列表（list）在python中使用很是普遍，固然常常会在访问列表的时候增长或者删除一些元素。好比，下面这个函数，试图删掉列表中为3的倍数的元素：

测试一下，

好像没什么错，不过这只是运气好

上面的例子中，6这个元素就没有被删除。若是在modify_lst函数中print idx， item就能够发现端倪：lst在变短，但idx是递增的，因此在上面出错的例子中，当3被删除以后，6变成了lst的第2个元素（从0开始）。在C++中，若是遍历容器的时候用迭代器删除元素，也会有一样的问题。

若是逻辑比较简单，使用list comprehension是不错的注意

第六，闭包与lambda

这个也是老生长谈的例子，在其余语言也有相似的状况。先看一个例子:

create_multipliers函数的返回值时一个列表，列表的每个元素都是一个函数 －－ 将输入参数x乘以一个倍数i的函数。预期的结果时0，2，4，6，8. 但结果是5个8，意外不意外。

因为出现这个陷阱的时候常用了lambda，因此可能会认为是lambda的问题，但lambda表示不肯意背这个锅。问题的本质在与python中的属性查找规则，LEGB（local，enclousing，global，bulitin），在上面的例子中，i就是在闭包做用域（enclousing），而Python的闭包是 迟绑定 ， 这意味着闭包中用到的变量的值，是在内部函数被调用时查询获得的。

解决办法也很简单，那就是变闭包做用域为局部做用域。

第七，定义del

大多数计算机专业的同窗可能都是先学的C、C++，构造、析构函数的概念应该都很是熟。因而，当切换到python的时候，天然也想知道有没有相应的函数。好比，在C++中很是有名的RAII，即经过构造、析构来管理资源（如内存、文件描述符）的声明周期。那在python中要达到一样的效果怎么作呢，即须要找到一个对象在销毁的时候必定会调用的函数，因而发现了init, del函数，可能简单写了两个例子发现确实也能工做。但事实上可能掉进了一个陷阱，在python documnet是有描述的：

Circular references which are garbage are detected when the option cycle detector is enabled (it’s on by default), but can only be cleaned up if there are no Python-level del() methods involved.

简单来讲，若是在循环引用中的对象定义了del,那么python gc不能进行回收，所以，存在内存泄漏的风险

第八，不一样的姿式import同一个module

示例在stackoverflow的例子上稍做修改，假设如今有一个package叫mypackage，里面包含三个python文件：mymodule.py, main.py, init.py。mymodule.py代码以下：

main.py代码以下：

运行python main.py，结果以下：

updated list [1] 4406700752
module in get 4406700920
lets check []
复制代码

从运行结果能够看到，在add 和 get函数中import的mymodule不是同一个module，ID不一样。固然，在python2.7.10中，须要main.py的第13行才能出现这样的效果。你可能会问，谁会写出第13行这样的代码呢？事实上，在不少项目中，为了import的时候方便，会往sys.path加入一堆路径。那么在项目中，你们赞成一种import方式就很是有必要了

第九，python升级

python3.x并不向后兼容，因此若是从2.x升级到3.x的时候得当心了，下面列举两点：

在python2.7中，range的返回值是一个列表；而在python3.x中，返回的是一个range对象。

map()、filter()、 dict.items()在python2.7返回列表，而在3.x中返回迭代器。固然迭代器大多数都是比较好的选择，更加pythonic，可是也有缺点，就是只能遍历一次。在instagram的分享中，也提到由于这个致使的一个坑爹的bug。

第十：++i —i

这个陷阱主要是坑来自C、C++背景的同窗。简单来讲，++i是对i取两次正号，—i是对i取两次负号，运算完以后i的值不变。

第十一： setattr getattr getattribute

Python中有大量的magic method（形似xx），其中许多跟属性访问有关，好比get， set，delete_，getattr, setattr, delattr, getattribute。前三个跟descriptor相关，详细可参见《python descriptor 详解》。坑爹的是，getattr与setattr相差很大，在《python属性查找（attribute look up）》一文中有详细介绍。简单说来，setattr与getattribute是对应的，都是修改python默认的属性修改、查找机制，而getattr只是默认查找机制没法找到属性的时候才会调用，setattr应该叫setattribute__才恰当！

第负一，gil

以GIL结尾，由于gil是Python中你们公认的缺陷！

其余语言过来的同窗可能看到python用threading模块，拿过来就用，结果发现效果不对啊，而后就会喷，什么鬼

总结：

毫无疑问的说，python是很是容易上手，也很是强大的一门语言。python很是灵活，可定制化很强。同时，也存在一些陷阱，搞清楚这些陷阱可以更好的掌握、使用这么语言。本文列举了一些python中的一些缺陷，这是一份不彻底列表，欢迎你们补充。