为什么“进口”不好？

Question

为什么“进口”不好？建议不要使用import *在Python里。能不能请大家分享一下原因，这样我下次就可以避免这样做了吗？

Answer 1

• 因为它在您的命名空间中放置了很多东西(可能会从以前的导入中隐藏一些其他对象，而您不会知道)。

• 因为您不知道什么是导入的，并且很难找到从哪个模块导入了某个东西(可读性)。

• 因为你不能使用像这样的酷工具pyflakes静态地检测代码中的错误。

Answer 2

根据Python的禅宗:

外显好于内隐。

..你不能反驳，对吧？

Answer 3

你不能通过**locals()去参加活动，是吗？

因为Python缺少一个“包含”语句，和这个self参数是显式的，和范围规则非常简单，通常很容易将手指指向一个变量并判断该对象来自何处-不需要读取其他模块，也不需要任何IDE(因为语言非常动态，这在自省方面是有限的)。

这个import *打破了所有这些。

此外，它还具有隐藏bug的具体可能性。

import os, sys, foo, sqlalchemy, mystufffrom bar import *

现在，如果BAR模块有任何“os", "mystuff“，等等.属性，它们将覆盖显式导入的属性，并可能指向非常不同的内容。__all__在BAR中通常是明智的-这说明了将隐式导入的内容-但是，如果不读取和解析BAR模块并遵循以下步骤，仍然很难跟踪对象来自何处它的进口品。网络import *当我拥有一个项目时，第一件事就是修复。

别误会我：如果import *如果失踪了，我会哭着要它。但必须谨慎使用。一个好的用例是在另一个模块上提供一个Facade接口。同样，使用条件导入语句，或者在函数/类命名空间中导入，需要遵守一些规则。

我认为，在中等到大型的项目中，或者有几个贡献者的小项目中，在静态分析中需要最少的卫生-至少运行一片热片，或者更好地运行一个配置得当的化纤板-以便在它们发生之前捕捉到几种bug。

当然，既然这是python-你可以自由地打破规则，去探索-但是要小心那些可能会增长十倍的项目，如果源代码缺少纪律，这将是一个问题。