为什么“import *”不好？

Question

在Python中，不建议使用 import * 这种方式。

有没有人能告诉我这样做的原因，这样我下次就能避免使用了？

Answer 1

你不会把 **locals() 传给函数，对吧？

因为Python没有“包含”这样的语句，而且 self 参数是明确的，再加上作用域规则很简单，通常很容易找到一个变量的来源——不需要去看其他模块，也不需要任何类型的IDE（因为这些工具在动态语言上有局限性）。

但是，使用 import * 就会打破这一切。

此外，它还有可能隐藏一些错误。

import os, sys, foo, sqlalchemy, mystuff
from bar import *

现在，如果bar模块里有像“os”、“mystuff”这样的属性，它们会覆盖那些明确导入的属性，并且可能指向完全不同的东西。在bar模块中定义 __all__ 通常是明智的——这表示哪些内容会被隐式导入——但即便如此，想要追踪对象的来源还是很难，必须阅读和解析bar模块，并且跟踪它的导入。对于我来说，当接手一个项目时，首先要解决的就是 import * 的问题。

不要误解我的意思：如果没有 import *，我会很想要它。但它必须小心使用。一个好的用例是为另一个模块提供一个外部接口。同样，条件导入语句或在函数/类命名空间内的导入也需要一些自律。

我认为在中大型项目中，或者在一些有多个贡献者的小项目中，至少需要保持一定的代码规范——至少要运行pyflakes，或者更好的是，配置好pylint，以便在错误发生之前捕捉到各种问题。

当然，因为这是Python——你可以随意打破规则，去探索——但要小心那些可能会快速增长的项目，如果源代码缺乏规范，那将会是个问题。

Answer 2

根据Python之禅的说法：

明确的比隐含的要好。

... 这个说法没错吧？

Answer 3

• 因为它会把很多东西放进你的命名空间里（可能会覆盖之前导入的某些对象，你可能根本不知道）。

• 因为你不知道到底导入了哪些东西，也不容易找到某个东西是从哪个模块导入的（可读性差）。

• 因为你无法使用一些很酷的工具，比如 pyflakes 来静态检测你代码中的错误。