21

在导入代码的各种方式中，与其他方式相比，有哪些方式更适合使用？这个链接http://effbot.org/zone/import-confusion.htm简而言之就是

from foo.bar import MyClass

在正常情况下或除非您知道自己在做什么，否则不是导入 MyClass 的首选方式。（相反，更好的方法是：

import foo.bar as foobaralias

然后在代码中，访问 MyClass 使用

foobaralias.MyClass

)

简而言之，似乎上面引用的链接是说从模块中导入所有内容通常会更好，而不仅仅是模块的一部分。

但是，我链接的那篇文章确实很旧。

我还听说，至少在 Django 项目的上下文中，最好只导入您想要使用的类，而不是整个模块。据说这种形式有助于避免循环导入错误或至少使 django 导入系统不那么脆弱。有人指出，Django 自己的代码似乎更喜欢“from x import y”而不是“import x”。

假设我正在处理的项目不使用__init__.py...的任何特殊功能（我们所有的__init__.py文件都是空的），我应该使用哪种导入方法，为什么？

4

3 回答 3

13

首先，也是主要的导入规则：永远不要使用from foo import *.

这篇文章正在讨论周期性导入的问题，该问题今天仍然存在于结构不良的代码中。我不喜欢周期性进口；它们的存在是一个强烈的信号，表明某些模块做得太多，需要拆分。如果出于某种原因您需要使用无法重新排列的循环导入代码，这import foo是唯一的选择。

import foo在大多数情况下，和之间没有太大区别from foo import MyClass。我更喜欢第二种，因为涉及的打字更少，但我可能使用第一种的原因有几个：

  • 模块和类/值具有不同的名称。当导入值的名称与模块无关时，读者可能很难记住特定导入的来源。

    • 好的：import myapp.utils as utils; utils.frobnicate()
    • 好的：import myapp.utils as U; U.frobnicate()
    • 坏的：from myapp.utils import frobnicate

  • 您正在从一个模块中导入大量值。保存您的手指和读者的眼睛。

    • 坏的：from myapp.utils import frobnicate, foo, bar, baz, MyClass, SomeOtherClass, # yada yada
于 2009-11-09T21:56:50.417 回答
6

对我来说，这取决于情况。如果它是一个唯一命名的方法/类（即，不是process()或类似的东西），并且您将经常使用它，那么请节省输入并执行from foo import MyClass.

如果你从一个模块中导入多个东西，最好只导入模块，然后做module.bar, module.foo, module.baz等，以保持命名空间干净。

你还说

据说这种形式有助于避免循环导入错误或至少使 django 导入系统不那么脆弱。有人指出，Django 自己的代码似乎更喜欢“from x import y”而不是“import x”。

我看不出一种或另一种方式如何有助于防止循环进口。原因是即使您这样做，也会导入from x import yALL of 。x只有y被带入当前命名空间，但整个模块x被处理。试试这个例子：

在 test.py 中，输入以下内容：

def a():
    print "a"

print "hi"

def b():
    print "b"

print "bye"

然后在“runme.py”中，输入：

from test import b

b()

然后就做python runme.py

您将看到以下输出：

hi
bye
b

所以 test.py 中的所有东西都运行了，即使你只导入了b

于 2009-11-09T22:10:43.773 回答
2

后者的优点是 MyClass 的来源更加明确。前者将 MyClass 放在当前命名空间中，因此代码可以只使用不合格的 MyClass。因此，对于阅读定义 MyClass 的代码的人来说，这不太明显。

于 2009-11-09T21:49:24.513 回答