blocks|key|1720027|text|我通常会在模块级使用import+X。如果只需要模块中的单个对象，请使用from+X+import+Y。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1720028|只有在遇到名称冲突时才使用import+X+as+Y。|1720029|当模块用作主模块时，我只在函数级使用imports来导入我需要的东西，比如：|1720030|def+main():
++import+sys
++if+len(sys.argv)+>+1:
+++++pass|code-block|syntax|javascript|1720031|HTH|1720032|entityMap^0|A|8|10|F|0|D|D|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|10|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|11|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|12|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|R|$]]

I would normally use <code>import X</code> on module level. If you only need a single object from a module, use <code>from X import Y</code>. 

Only use <code>import X as Y</code> in case you're otherwise confronted with a name clash.

I only use imports on function level to import stuff I need when the module is used as the main module, like:

<pre><code>def main():
 import sys
 if len(sys.argv) &gt; 1:
 pass
</code></pre>

HTH

blocks|key|1505043|text|在我们公司的生产代码中，我们尝试遵循以下规则。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1505044|我们将导入放在文件的开头，紧跟在主文件的文档字符串之后，例如：|1505045|"""
Registry+related+functionality.
"""
import+wx
#+...|code-block|syntax|javascript|1505046|现在，如果我们导入的类是导入模块中为数不多的类之一，我们将直接导入名称，因此在代码中我们只需使用最后一部分，例如：|1505047|from+RegistryController+import+RegistryController
from+ui.windows.lists+import+ListCtrl,+DynamicListCtrl|1505048|然而，有些模块包含几十个类，例如所有可能的异常列表。然后我们导入模块本身，并在代码中引用它：|1505049|from+main.core+import+Exceptions
#+...
raise+Exceptions.FileNotFound()|1505050|我们尽可能少使用import+X+as+Y，因为它使得搜索特定模块或类的用法变得困难。但是，有时如果您希望导入两个同名但存在于不同模块中的类，则必须使用它，例如：|offset|length|style|CODE|1505051|from+Queue+import+Queue
from+main.core.MessageQueue+import+Queue+as+MessageQueue|1505052|一般来说，我们不会在方法中进行导入--它们只会使代码变得更慢，可读性更差。有些人可能会发现这是一个很容易解决循环导入问题的好方法，但更好的解决方案是代码重组。|1505053|entityMap^0|0|0|0|0|0|0|0|8|D|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|14|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|15|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|16|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|19|8|@$S|1A|T|1B|U|V]]|9|@]|A|$]]|$1|W|3|X|5|F|7|1C|8|@]|9|@]|A|$G|H]]|$1|Y|3|Z|5|6|7|1D|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|11|$]]

In production code in our company, we try to follow the following rules.

We place imports at the beginning of the file, right after the main file's docstring, e.g.:

<pre><code>"""
Registry related functionality.
"""
import wx
# ...
</code></pre>

Now, if we import a class that is one of few in the imported module, we import the name directly, so that in the code we only have to use the last part, e.g.:

<pre><code>from RegistryController import RegistryController
from ui.windows.lists import ListCtrl, DynamicListCtrl
</code></pre>

There are modules, however, that contain dozens of classes, e.g. list of all possible exceptions. Then we import the module itself and reference to it in the code:

<pre><code>from main.core import Exceptions
# ...
raise Exceptions.FileNotFound()
</code></pre>

We use the <code>import X as Y</code> as rarely as possible, because it makes searching for usage of a particular module or class difficult. Sometimes, however, you have to use it if you wish to import two classes that have the same name, but exist in different modules, e.g.:

<pre><code>from Queue import Queue
from main.core.MessageQueue import Queue as MessageQueue
</code></pre>

As a general rule, we don't do imports inside methods -- they simply make code slower and less readable. Some may find this a good way to easily resolve cyclic imports problem, but a better solution is code reorganization.

blocks|key|1505114|text|如果同一模块/类有不同的实现，则import+X+as+Y非常有用。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1505115|使用一些嵌套的try..import..except+ImportError..import，您可以在代码中隐藏实现。请参阅lxml+etree+import+example|1505116|try:
++from+lxml+import+etree
++print("running+with+lxml.etree")
except+ImportError:
++try:
++++#+Python+2.5
++++import+xml.etree.cElementTree+as+etree
++++print("running+with+cElementTree+on+Python+2.5%2B")
++except+ImportError:
++++try:
++++++#+Python+2.5
++++++import+xml.etree.ElementTree+as+etree
++++++print("running+with+ElementTree+on+Python+2.5%2B")
++++except+ImportError:
++++++try:
++++++++#+normal+cElementTree+install
++++++++import+cElementTree+as+etree
++++++++print("running+with+cElementTree")
++++++except+ImportError:
++++++++try:
++++++++++#+normal+ElementTree+install
++++++++++import+elementtree.ElementTree+as+etree
++++++++++print("running+with+ElementTree")
++++++++except+ImportError:
++++++++++print("Failed+to+import+ElementTree+from+any+known+place")|code-block|syntax|javascript|1505117|entityMap|0|LINK|mutability|MUTABLE|url|http://codespeak.net/lxml/tutorial.html^0|G|D|0|7|13|1Q|P|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@$9|10|A|11|1|12]]|E|$]]|$1|H|3|I|5|J|7|13|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|14|8|@]|D|@]|E|$]]]|N|$O|$5|P|Q|R|E|$S|T]]]]

The <code>import X as Y</code> is useful if you have different implementations of the same module/class.

With some nested <code>try..import..except ImportError..import</code>s you can hide the implementation from your code. See <a href="http://codespeak.net/lxml/tutorial.html" rel="nofollow noreferrer">lxml etree import example</a>:

<pre><code>try:
 from lxml import etree
 print("running with lxml.etree")
except ImportError:
 try:
 # Python 2.5
 import xml.etree.cElementTree as etree
 print("running with cElementTree on Python 2.5+")
 except ImportError:
 try:
 # Python 2.5
 import xml.etree.ElementTree as etree
 print("running with ElementTree on Python 2.5+")
 except ImportError:
 try:
 # normal cElementTree install
 import cElementTree as etree
 print("running with cElementTree")
 except ImportError:
 try:
 # normal ElementTree install
 import elementtree.ElementTree as etree
 print("running with ElementTree")
 except ImportError:
 print("Failed to import ElementTree from any known place")
</code></pre>

blocks|key|1720325|text|其他人已经涵盖了这里的大部分内容，但我只想添加一个案例，当我尝试一个新版本的类或模块时，我将(暂时)使用import+X+as+Y。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1720326|因此，如果我们要迁移到模块的新实现，但又不想一次切掉所有的代码库，我们可能会编写一个xyz_new模块，并在已迁移的源文件中执行以下操作：|1720327|import+xyz_new+as+xyz|code-block|syntax|javascript|1720328|然后，一旦我们删除了整个代码库，我们就只需要用xyz_new替换xyz模块，并将所有的导入改回|1720329|import+xyz|1720330|entityMap^0|1G|D|0|16|7|0|0|N|7|W|3|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|Y|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|Z|8|@$9|10|A|11|B|C]|$9|12|A|13|B|C]]|D|@]|E|$]]|$1|O|3|P|5|J|7|14|8|@]|D|@]|E|$K|L]]|$1|Q|3|-4|5|6|7|15|8|@]|D|@]|E|$]]]|R|$]]

Others have covered most of the ground here but I just wanted to add one case where I will use <code>import X as Y</code> (temporarily), when I'm trying out a new version of a class or module.

So if we were migrating to a new implementation of a module, but didn't want to cut the code base over all at one time, we might write a <code>xyz_new</code> module and do this in the source files that we had migrated:

<pre><code>import xyz_new as xyz
</code></pre>

Then, once we cut over the entire code base, we'd just replace the <code>xyz</code> module with <code>xyz_new</code> and change all of the imports back to

<pre><code>import xyz
</code></pre>

blocks|key|1720398|text|不要这样做：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1720399|from+X+import+*|code-block|syntax|javascript|1720400|除非你绝对确定你会用到该模块中的每一件事。即使这样，您也应该重新考虑使用不同的方法。|1720401|除此之外，这只是一个风格问题。|1720402|from+X+import+Y|1720403|很好，省去了你大量的打字工作。当我经常使用其中的一些东西时，我倾向于使用它，但如果你从该模块导入了很多东西，你可能会得到如下所示的import语句：|1720404|from+X+import+A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P|1720405|你明白了吧。这就是像这样的导入|1720406|import+X|1720407|变得有用。或者如果我不经常使用X中的任何东西。|1720408|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|10|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|12|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|14|8|@]|9|@]|A|$E|F]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|D|7|16|8|@]|9|@]|A|$E|F]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

DON'T do this:

<pre><code>from X import *
</code></pre>

unless you are absolutely sure that you will use each and every thing in that module. And even then, you should probably reconsider using a different approach.

Other than that, it's just a matter of style.

<pre><code>from X import Y
</code></pre>

is good and saves you lots of typing. I tend to use that when I'm using something in it fairly frequently But if you're importing a lot from that module, you could end up with an import statement that looks like this:

<pre><code>from X import A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P
</code></pre>

You get the idea. That's when imports like

<pre><code>import X
</code></pre>

become useful. Either that or if I'm not really using anything in X very frequently.

blocks|key|1720446|text|如果你有一个写得很好的库，在python中有时就是这样，你应该直接导入它并使用它。编写良好的库往往需要自己的生命和语言，从而产生易于阅读的-code，其中您很少引用该库。当一个库写得很好时，你不应该经常需要重命名或其他任何东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1720447|import+gat

node+=+gat.Node()
child+=+node.children()|code-block|syntax|javascript|1720448|有时不能这样写，或者你想从你导入的库中取下一些东西。|1720449|from+gat+import+Node,+SubNode

node+=+Node()
child+=+SubNode(node)|1720450|有时，您可以这样做很多事情，如果您的导入字符串超过80列，那么这样做是个好主意：|1720451|from+gat+import+(
++++Node,+SubNode,+TopNode,+SuperNode,+CoolNode,
++++PowerNode,+UpNode
)|1720452|最好的策略是将所有这些导入放在文件的顶部。最好是按字母顺序，先导入-statements，然后从导入-statements。|1720453|现在我告诉你为什么这是最好的约定。|1720454|Python完全可以有一个自动导入，当在全局名称空间中找不到值时，它会从主导入中查找值。但这不是一个好主意。我简短地解释一下原因。抛开它比简单的导入更复杂的实现，程序员不会过多地考虑依赖关系，并找出应该从哪里导入的东西，而不是仅仅查看导入。|1720455|需要找出依赖关系是人们讨厌"from+...+import+*“的原因之一。不过，也有一些不好的例子需要这样做，例如opengl+-wrappings。|1720456|因此，导入定义实际上对于定义程序的依赖性是有价值的。这是你应该如何利用它们的方式。从它们中，你可以快速地检查一些奇怪的函数是从哪里导入的。|1720457|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|11|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|12|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|16|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|17|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|18|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|19|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Z|$]]

When you have a well-written library, which is sometimes case in python, you ought just import it and use it as it. Well-written library tends to take life and language of its own, resulting in pleasant-to-read -code, where you rarely reference the library. When a library is well-written, you ought not need renaming or anything else too often.

<pre><code>import gat

node = gat.Node()
child = node.children()
</code></pre>

Sometimes it's not possible to write it this way, or then you want to lift down things from library you imported.

<pre><code>from gat import Node, SubNode

node = Node()
child = SubNode(node)
</code></pre>

Sometimes you do this for lot of things, if your import string overflows 80 columns, It's good idea to do this:

<pre><code>from gat import (
 Node, SubNode, TopNode, SuperNode, CoolNode,
 PowerNode, UpNode
)
</code></pre>

The best strategy is to keep all of these imports on the top of the file. Preferrably ordered alphabetically, import -statements first, then from import -statements.

Now I tell you why this is the best convention.

Python could perfectly have had an automatic import, which'd look from the main imports for the value when it can't be found from global namespace. But this is not a good idea. I explain shortly why. Aside it being more complicated to implement than simple import, programmers wouldn't be so much thinking about the depedencies and finding out from where you imported things ought be done some other way than just looking into imports.

Need to find out depedencies is one reason why people hate "from ... import *". Some bad examples where you need to do this exist though, for example opengl -wrappings.

So the import definitions are actually valuable as defining the depedencies of the program. It is the way how you should exploit them. From them you can quickly just check where some weird function is imported from.

blocks|key|1720516|text|我同意杰森不使用|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1720517|from+X+import+*|code-block|syntax|javascript|1720518|但在我的例子中(我不是一个专家程序员，所以我的代码不能很好地满足编码风格)我通常在我的程序中创建一个包含所有常量的文件，比如程序版本、作者、错误消息等等，所以这个文件只是定义，然后我进行导入|1720519|from+const+import+*|1720520|这为我节省了很多时间。但它是唯一具有该导入的文件，这是因为该文件中的所有内容都只是变量声明。|1720521|在包含类和定义的文件中执行这种导入可能会很有用，但当您必须阅读这些代码时，您会花费大量时间来定位函数和类。|1720522|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I'm with Jason in the fact of not using

<pre><code>from X import *
</code></pre>

But in my case (i'm not an expert programmer, so my code does not meet the coding style too well) I usually do in my programs a file with all the constants like program version, authors, error messages and all that stuff, so the file are just definitions, then I make the import

<pre><code>from const import *
</code></pre>

That saves me a lot of time. But it's the only file that has that import, and it's because all inside that file are just variable declarations.

Doing that kind of import in a file with classes and definitions might be useful, but when you have to read that code you spend lots of time locating functions and classes.

blocks|key|1720543|text|上面有人说|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1720544|from+X+import+A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P|code-block|syntax|javascript|1720545|等同于|1720546|import+X|1720547|import+X允许直接修改A-P，而from+X+import+...则创建A-P的副本。对于from+X+import+A..P，如果变量被修改，您将无法获得变量的更新。如果你修改了它们，你只修改了你的副本，但是X知道你的修改。|offset|length|style|CODE|1720548|如果A-P是函数，你不会知道其中的区别。|1720549|entityMap^0|0|0|0|0|0|8|J|H|1C|I|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|Y|8|@$M|Z|N|10|O|P]|$M|11|N|12|O|P]|$M|13|N|14|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|T|$]]

Someone above said that

<pre><code>from X import A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P
</code></pre>

is equivalent to

<pre><code>import X
</code></pre>

<code>import X</code> allows direct modifications to A-P, while <code>from X import ...</code> creates copies of A-P. For <code>from X import A..P</code> you do not get updates to variables if they are modified. If you modify them, you only modify your copy, but X does know about your modifications.

If A-P are functions, you won't know the difference.

I am a little confused by the multitude of ways in which you can import modules in Python. 

<pre><code>import X
import X as Y
from A import B
</code></pre>

I have been reading up about scoping and namespaces, but I would like some practical advice on what is the best strategy, under which circumstances and why. Should imports happen at a module level or a method/function level? In the <code>__init__.py</code> or in the module code itself?

My question is not really answered by "<a href="https://stackoverflow.com/questions/45122/python-packages-import-by-class-not-file">Python packages - import by class, not file</a>" although it is obviously related.

What are good rules of thumb for Python imports?

Python

我对在Python中导入模块的多种方式感到有点困惑。import Ximport X as Yfrom A import B我一直在阅读有关作用域和命名空间的内容，但我想要一些关于什么是最佳策略、在什么情况下以及为什么是最佳策略的实用建议。导入应该发生在模块级别还是方法/函数级别？在__init__.py中还是在模块代...

问Python导入有哪些好的经验法则？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Python导入有哪些好的经验法则？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Python导入有哪些好的经验法则？
EN