这个特性用起来很爽，比写name=human[0]之类的不知道高到哪里去了。所以，这一特性往往被滥用，一个human在程序的各处通过上面的方式unpack。  

然而如果后来需要在human中插入一个表示性别的数据sex，那么对于所有的这种unpack都需要进行修改，即使在有些逻辑中并不会使用到性别。

有如下几种方式解决这一问题：  

老老实实写name=human[0]这种代码，在需要使用性别信息处加上sex=human[3]

使用dict来表示human

使用namedtuple

到处都是import *

import *是一种懒惰的行为，它不仅会污染当前的命名空间，并且还会使得pyflakes等代码检查工具失效。在后续查看代码或者debug的过程中，往往也很难从一堆import *中找到一个第三方函数的来源。  

可以说这种习惯是百害而无一利的。  

文件操作

文件操作不要使用裸奔的f = open(‘filename’)了，使用with open(‘filename’) as f来让context manager帮你处理异常情况下的关闭文件等乱七八糟的事情多好。  

野蛮使用class.name判断类型

我曾经遇见过一个bug：为了实现某特定功能，我新写了一个class B(A)，在B中重写了A的若干函数。整个实现很简单，但是就是有一部分A的功能无法生效。最后追查到的原因，就是在一些逻辑代码中，硬性的判断了entity.__class__.__name__ == ‘A’。  

除非你就是想限定死继承层级中的当前类型（也就是，屏蔽未来可能会出现的子类），否则，不要使用__class__.__name__，而改用isinstance这个内建函数。毕竟，Python把这两个变量的名字都刻意带上那么多下划线，本来就是不太想让你用嘛。  

循环内部有多层函数调用

循环内部有多层函数调用，有如下两方面的隐患：  

Python没有inline函数，所以函数调用本来就会导致一定的开销，尤其是本身逻辑简单的时候，这个开销所占的比例就会挺可观的。

更严重的是，在之后维护这份代码时，会容易让人忽略掉函数是在循环中被调用的，所以容易在函数内部添加了一些开销较大却不必每次循环都调用的函数，比如time.localtime()。如果是直接一个平铺直叙的循环，我想大部分的程序员都应该知道把time.localtime()写到循环的外面，但是引入多层的函数调用之后，就不一定了哦。

所以我建议，在循环内部，如非特别复杂的逻辑，都应该直接写在循环里，不要进行函数调用。如果一定要包装一层函数调用，应该在函数的命名或注释中，提示后续的维护者，这个函数会在循环内部使用。  

Python是一门非常容易入门的语言，严格的缩进要求和丰富的内置数据类型，使得大部分Python代码都能做到比较好的规范。但是，不严格要求自己，也很容易就写出犯二的代码。上面列出的只是很小的一部分，唯有多读、多写、多想，才能培养敏锐的代码嗅觉，第一时间发现坏味道啊。