你应该知道的的Python陷阱

开发 后端
我个人对陷阱的定义是这样的:代码看起来可以工作,但不是以你“想当然”的方式。如果一段代码直接出错,抛出了异常,我不认为这是陷阱。

[[404209]]

 我个人对陷阱的定义是这样的:代码看起来可以工作,但不是以你“想当然”的方式。如果一段代码直接出错,抛出了异常,我不认为这是陷阱。比如,Python程序员应该都遇到过的“UnboundLocalError”, 示例: 

  1. >>> a=1  
  2. >>> def func():  
  3. ...     a+=1  
  4. ...     print a  
  5. ...   
  6. >>> func()  
  7. traceback (most recent call last):  
  8. File "<stdin>", line 1, in <module>  
  9. File "<stdin>", line 2, in func  
  10. UnboundLocalError: local variable 'a' referenced before assignment    

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

  1. import random  
  2. def func(ok):  
  3.     if ok:  
  4.         a = random.random()  
  5.     else:  
  6.         import random  
  7.         a = random.randint(1, 10)  
  8.     return a  
  9. func(True)# UnboundLocalError: local variable 'random' referenced before assignment 

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

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

第一:以mutable对象作为默认参数

这个估计是最广为人知的了,Python和其他很多语言一样,提供了默认参数,默认参数确实是个好东西,可以让函数调用者忽略一些细节(比如GUI编程,Tkinter,QT),对于lambda表达式也非常有用。但是如果使用了可变对象作为默认参数,那么事情就不那么愉快了 

  1. >>> def f(lst = []):  
  2. ...     lst.append(1)  
  3. ...     return lst  
  4. ...  
  5. >>> f()  
  6. [1]  
  7. >>> f()  
  8. [1, 1] 

惊喜不惊喜?!究其原因,python中一切都是对象,函数也不列外,默认参数只是函数的一个属性。而默认参数在函数定义的时候已经求值了。

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

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

  1. >>> import time  
  2. >>> def report(when=time.time()):  
  3. ...     return when  
  4. ...   
  5. >>> report()  
  6. 1500113234.487932  
  7. >>> report()  
  8. 1500113234.487932 

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

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

  1. >>> def report(when=None):  
  2. ...     if when is None:  
  3. ...             when = time.time()  
  4. ...     return when  
  5. ...   
  6. >>> report()  
  7. 1500113446.746997  
  8. >>> report()  
  9. 1500113448.552873 

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

一般来说,二者是等价的,至少看起来是等价的(这也是陷阱的定义 — 看起来都OK,但不一定正确)。 

  1. >>> x=1;x += 1;print x  
  2.  
  3. >>> x=1;xx = x+1;print x  
  4.  
  5. >>> x=[1];x+=[2];print x  
  6. [1, 2]  
  7. >>> x=[1];xx=x+[2];print x  
  8. [1, 2] 

呃,被光速打脸了? 

  1. >>> x=[1];print id(x);xx=x+[2];print id(x)  
  2. 4357132800  
  3. 4357132728  
  4. >>> x=[1];print id(x);x+=[2];print id(x)  
  5. 4357132800  
  6. 4357132800   

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

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

小括号(parenthese)在各种编程语言中都有广泛的应用,python中,小括号还能表示元组(tuple)这一数据类型, 元组是immutable的序列。 

  1. >>> a = (1, 2)  
  2. >>> type(a)  
  3. <type 'tuple'>  
  4. >>> type(())  
  5. <type 'tuple'> 

但如果只有一个元素呢 

  1. >>> a=(1)  
  2. >>> type(a)  
  3. <type 'int'> 

神奇不神奇,如果要表示只有一个元素的元组,正确的姿势是: 

  1. >>> a=(1,)  
  2. >>> type(a)  
  3. <type 'tuple'> 

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

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

很简单嘛: 

  1. >>> a= [[]] * 10  
  2. >>> a  
  3. [[], [], [], [], [], [], [], [], [], []]  
  4. >>> a[0].append(10)  
  5. >>> a[0]  
  6. [10] 

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

  1. >>> a[1]  
  2. [10]  
  3. >>> a  
  4. [[10], [10], [10], [10], [10], [10], [10], [10], [10], [10]] 

我猜,这应该不是你预期的结果吧,究其原因,还是因为python中list是可变对象,上述的写法大家都指向的同一个可变对象,正确的姿势 

  1. >>> a = [[] for _ in xrange(10)]  
  2. >>> a[0].append(10)  
  3. >>> a  
  4. [[10], [], [], [], [], [], [], [], [], []] 

另外一个在实际编码中遇到的问题,dict.fromkeys, 也有异曲同工之妙:创建的dict的所有values指向同一个对象。

  1. fromkeys(seq[, value]) 

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

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

列表(list)在python中使用非常广泛,当然经常会在访问列表的时候增加或者删除一些元素。比如,下面这个函数,试图删掉列表中为3的倍数的元素: 

  1. >>> def modify_lst(lst):  
  2. ...     for idx, elem in enumerate(lst):  
  3. ...         if elem % 3 == 0:  
  4. ...             del lst[idx]  
  5. ... 

测试一下, 

  1. >>> lst = [1,2,3,4,5,6]  
  2. >>> modify_lst(lst)  
  3. >>> lst   
  4. [1, 2, 4, 5] 

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

  1. >>> lst = [1,2,3,6,5,4]  
  2. >>> modify_lst(lst)  
  3. >>> lst  
  4. [1, 2, 6, 5, 4] 

上面的例子中,6这个元素就没有被删除。如果在modify_lst函数中print idx, item就可以发现端倪:lst在变短,但idx是递增的,所以在上面出错的例子中,当3被删除之后,6变成了lst的第2个元素(从0开始)。在C++中,如果遍历容器的时候用迭代器删除元素,也会有同样的问题。

如果逻辑比较简单,使用list comprehension是不错的注意

第六,闭包与lambda

这个也是老生长谈的例子,在其他语言也有类似的情况。先看一个例子: 

  1. >>> def create_multipliers():  
  2. ...     return [lambda x:i*x for i in range(5)]  
  3. ...   
  4. >>> for multiplier in create_multipliers():  
  5. ...     print multiplier(2)  
  6. ... 

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

由于出现这个陷阱的时候经常使用了lambda,所以可能会认为是lambda的问题,但lambda表示不愿意背这个锅。问题的本质在与python中的属性查找规则,LEGB(local,enclousing,global,bulitin),在上面的例子中,i就是在闭包作用域(enclousing),而Python的闭包是 迟绑定 , 这意味着闭包中用到的变量的值,是在内部函数被调用时查询得到的。

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

  1. >>> def create_multipliers():  
  2. ...     return [lambda x, ii = i:i*x for i in range(5)]  
  3. ... 

第七,定义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代码如下: 

  1. l = []  
  2. class A(object):   
  3.     pass 

main.py代码如下: 

  1. def add(x):  
  2.     from mypackage import mymodule  
  3.     mymodule.l.append(x)  
  4.     print "updated list",mymodule.l, id(mymodule)  
  5. def get():  
  6.     import mymodule  
  7.     print 'module in get', id(mymodule)  
  8.     return mymodule.l  
  9. if __name__ == '__main__':  
  10.     import sys  
  11.     sys.path.append('../')  
  12.     add(1)  
  13.     ret = get()  
  14.     print "lets check", ret  
  15. 运行python main.py,结果如下:  
  16. updated list [1] 4406700752  
  17. module in get 4406700920  
  18. 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相关,坑爹的是,getattr与setattr相差很大。简单说来,setattr与getattribute是对应的,都是修改python默认的属性修改、查找机制,而getattr只是默认查找机制无法找到属性的时候才会调用,setattr应该叫setattribute__才恰当!

第负一,gil

以GIL结尾,因为gil是Python中大家公认的缺陷!

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

总结:

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

 

责任编辑:庞桂玉 来源: Linux公社
相关推荐

2011-03-25 15:56:58

2019-06-03 08:04:43

Apache服务器命令

2013-01-09 13:55:43

2020-04-29 14:30:35

HTTPHTTPS前端

2023-01-10 09:24:47

Python编程语言

2022-11-04 08:22:14

编译代码C语言

2020-10-13 14:15:22

HTTPHTTP请求方法

2013-06-28 14:09:33

PHP库

2023-05-04 16:10:13

缓存前端

2020-11-25 10:18:20

MySQL

2013-05-31 02:25:47

WebWeb设计响应式

2014-12-08 10:39:15

2020-02-21 10:30:10

开发技能代码

2015-05-07 10:23:19

Android学习资源

2018-04-02 14:33:58

区块链投资存储技术

2013-05-23 11:11:58

Sailfish OSJolla手机操作系统

2017-06-06 11:59:26

Docker工具容器

2020-05-06 09:04:09

Python文件系统操作系统

2014-09-12 11:35:23

开源

2020-06-02 10:10:46

React前端组件
点赞
收藏

51CTO技术栈公众号