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 回答