程序员老司机们都要错的Python陷阱与缺陷列表

我个人对陷阱的定义是这样的:代码看起来可以工作,但不是以你“想当然“”的方式。如果一段代码直接出错,抛出了异常,我不认为这是陷阱。比如,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.   
  3. def func(ok): 
  4.     if ok: 
  5.         a = random.random() 
  6.     else: 
  7.         import random 
  8.         a = random.randint(1, 10) 
  9.     return a 
  10.   
  11. 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中一切都是对象,函数也不列外,默认参数只是函数的一个属性。而默认参数在函数定义的时候已经求值了。


  1. 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 给出了标准的解决办法:


  1. 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. 2  
  3. >>> x=1;x = x+1;print x 
  4. >>> x=[1];x+=[2];print x 
  5. [1, 2] 
  6. >>> x=[1];x=x+[2];print x 
  7. [1, 2] 

呃,被光速打脸了?


  1. >>> x=[1];print id(x);x=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.  
  3. >>> type(a) 
  4.  
  5. <type 'int'> 

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


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

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

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

很简单嘛:


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

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


  1. >>> a[1] 
  2.  
  3. [10] 
  4.  
  5. >>> a 
  6.  
  7. [[10], [10], [10], [10], [10], [10], [10], [10], [10], [10]] 

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


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

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

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


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

测试一下,


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

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


  1. >>> lst = [1,2,3,6,5,4] 
  2.  
  3. >>> modify_lst(lst) 
  4.  
  5. >>> lst 
  6.  
  7. [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.  
  3. ... return [lambda x:i*x for i in range(5)] 
  4.  
  5. ... 
  6.  
  7. >>> for multiplier in create_multipliers(): 
  8.  
  9. ... print multiplier(2) 
  10.  
  11. ... 

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.  
  3. ... return [lambda x, i = i:i*x for i in range(5)] 
  4.  
  5. ... 

第七,定义__del__

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


  1. 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.   
  6. def get(): 
  7.     import mymodule 
  8.     print 'module in get', id(mymodule) 
  9.     return mymodule.l 
  10.   
  11. if __name__ == '__main__': 
  12.     import sys 
  13.     sys.path.append('../') 
  14.     add(1) 
  15.      
  16.     ret = get() 
  17.     print "lets check", ret 

运行python main.py,结果如下:


  1. updated list [1] 4406700752 
  2. module in get 4406700920 
  3. 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。

第十,gil

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

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

总结:

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

本文作者:xybaby

来源:51CTO

时间: 2024-08-20 07:19:52

程序员老司机们都要错的Python陷阱与缺陷列表的相关文章

程序员必知的Python陷阱与缺陷列表

我个人对陷阱的定义是这样的:代码看起来可以工作,但不是以你"想当然""的方式.如果一段代码直接出错,抛出了异常,我不认为这是陷阱.比如,Python程序员应该都遇到过的"UnboundLocalError", 示例: >>> a=1    >>> def func():    ...     a+=1    ...     print a    ...    >>> func()    Tracebac

当程序员老去

           程序员将代码注入生命去打造互联网的浪潮之巅,当有一天他们老了,会走向那里,会做些什么?      很多年以后,在我60岁的那天早晨,天刚蒙蒙亮我就起床了,先去公园晨练,然后回来做早餐(50岁的时候我学会了做饭),送完外孙上学,刚好8点.由于北京从2020年开始单双月限行了,这个月是单月,所以只能挤地铁.人一如既往的多,一小伙子要给我让座,看了看他的小身板,我说不用,你也是干 IT 的吧,今天咱们都是程序员.     来到公司,墙上那条新贴上去的刺眼规定总是让我很不舒服:所有

app-作为程序员,你平时都用什么APP

问题描述 作为程序员,你平时都用什么APP 最近刚入手 一部MX4 pro 算是本人第一部真正意义上的智能机吧. 感觉应该把手机用起来,或者多学点东西,不知道作为程序员的你平时都用什么APP 当然 除了 微信 qq等一些常用的 主要是有关专业方面的资讯类的APP 可以用来学习 希望大家推荐一下~ 解决方案 程序员,也是和别人一样的用手机.手机不太适合于学习或其它,毕竟屏幕还在太小. 看一下相应的开发论坛,这还是可以的. 解决方案二: 手机限于屏幕.硬件.网络.电池等问题,能不能就不要用. 只有那

程序员天天那么忙都在干啥?

问题描述 我最近拿到一份工作发现程序员上班没那么累基本就是需求来了写写没需求就闲着加班的确很多加班的原因多半是晚上6点来个需求或者项目上线但是总的来说一天8小时+加班大部分时间还是闲着的是这样么 解决方案 解决方案二:基本都是需求不明确导致的瞎JB忙解决方案三:天天都是瞎JB忙解决方案四: 解决方案五:程序员不忙一般都是早9晚5双休一切按照法定,甚至more而且有提成,有奖金,加薪快,不累,轻松.是最接近上帝的职业了....解决方案六:你看人家马云,有钱了就可以做广告骂发改委.对出名女ceo耍流

老程序员的下场 程序员老了该怎么办?

&http://www.aliyun.com/zixun/aggregation/37954.html">nbsp; 长期从事编程活动的程序员都期望在50多岁时能爬到一个足够高的职位,或者能顺利的退休. 但我在这里讨论的可能是一个你还没有想过的问题:如果到那时你失业了呢? 50多岁时你的职业仕途会成为一个问题.如果你有很好的技术,有人雇你,你会有一个很高的职衔,或你是一个专家,或有很好的人际关系,你都有可能找到一个新的职务. 否则,你会从衣食无忧沦落为无家可归.这是真的.我55岁,

程序员,老的程序员.新的程序员.我们该不该用盗版.?我们用了多少盗版?

盗版是什么...??? 我们是程序员...当你发现..你别人在卖你写的代码的软件...(你花了不少心血.) 而没有经过你同意..你也没有得到什么回报..你是什么感觉... 且不说windows..我们使用盗版的myeclipse编程序... 然后部署到盗版的weblogic上面... 使用开源的东西从来不看是什么开源协议..直接就改源代码编译... 开始是以学习为目的...后来是以工作为目的.... 总之理由太多太多.... 我们又不是不懂电脑的人..明明知道是盗版..明明自己还在写程序...

直播时,阿里的老司机们都做了什么?

直播作为近来新兴的互动形态,已经成为近几年最风生水起的行业之一.在2016年仿佛进入了"千团大战"的繁华.欢聚时代10亿砸向虎牙和ME直播,斥资1亿签下主播MISS:腾讯4亿投资斗鱼,后者估值10亿美元:新成立的映客获得昆仑万维.复赛等机构的8000万人民币投资:易直播获得6000万人民币A轮融资:360推出花椒.秒拍推出一直播....网络直播正享受其最好的时光,直播"风口"成投资方必争之地. 然而网络直播也因为走的太快,而失去了出发的初心,主播行为.直播内容变得不

史上票房最高爱情动作片女主与红楼尤二姐竟都转行做了程序员?

10月24日,刚刚过去的"程序员节"让吃瓜群众的目光又转向了这群被称为"码农"的人. 在大众眼里,一件格纹棉麻衬衫.一副黑框眼镜彰,他们神秘又低调.他们的一生都和名叫"康姆皮优特"的机器人生活在一起.不分季节,不分昼夜,互相解读着一些令人摸不着头脑的奇怪符号.每天都要面对名叫"bug"的入侵分子. 但是--这只是大众的想法,许多程序员的生活也相当精彩. 首先要说的一位就是87版<红楼梦>中尤二姐的扮演者张明明. &

池老师说:程序员不该互相鄙视

简评:都说程序员之间存在着各种各样的鄙视链,其实在看完池建强老师的这篇文章,作为一个软件工程学生党的我,开始重新思考作为一个技术人的责任和对于技术的理解,技术人需要做好自己的技术,写出优秀的代码,让技术驱动业务,做出优秀的产品,让世界变得更好一些,这也是我选择了技术这个行业的最初动力,希望世界能够因为我们的努力而变得更加美好. 有阵子没写程序员相关的文章,干脆再来个程序员三部曲吧.为什么是再呢?因为写过很多三部曲了:) 题图:from zoommy 部分手绘 以前在文章里写过程序员鄙视链的问题,