PEP 08指出：
导入总是放在文件的顶部，紧随任何模块注释和文档字符串之后，以及模块全局变量和常量之前。
但是，如果仅在极少数情况下使用我要导入的类/方法/函数，那么在需要时进行导入肯定会更有效吗？
这不是吗？
class SomeClass(object):
def not_often_called(self)
from datetime import datetime
self.datetime = datetime.now()比这更有效？
from datetime import datetime
class SomeClass(object):
def not_often_called(self)
self.datetime = datetime.now()Answers:
模块导入非常快，但不是即时的。这意味着：
因此，如果您关心效率，则将进口放在首位。仅在您的分析显示有帮助的情况下，才将它们移入函数中（您进行了概要分析以查看最能改善性能的地方，对吗？）
我见过执行延迟导入的最佳原因是：
__init__.py插件的中，可能已导入但并未实际使用。例如Bazaar插件，它使用bzrlib的延迟加载框架。将import语句放在函数内部可以防止循环依赖。例如，如果您有两个模块X.py和Y.py，并且它们都需要互相导入，那么当您导入其中一个模块导致无限循环时，这将导致循环依赖。如果将import语句移动到一个模块中，则它将在调用该函数之前不会尝试导入另一个模块，并且该模块将已经被导入，因此不会出现无限循环。在此处阅读更多内容-effbot.org/zone/import-confusion.htm
我采用了将所有导入放入使用它们的函数中而不是放在模块顶部的做法。
我得到的好处是能够更可靠地进行重构。当我将一个功能从一个模块移动到另一个模块时，我知道该功能将继续使用其完整的测试遗留功能。如果我在模块的顶部放置了导入文件，那么当我移动一个函数时，我发现我花了很多时间来使新模块的导入文件完整而最少。重构IDE可能与此无关。
如其他地方提到的那样，存在速度损失。我已经在我的应用程序中对此进行了测量，发现对于我的目的而言它并不重要。
能够预先查看所有模块依赖性而无需借助搜索（例如grep），也很不错。但是，我关心模块依赖性的原因通常是因为我正在安装，重构或移动包含多个文件的整个系统，而不仅仅是一个模块。在这种情况下，无论如何，我将执行全局搜索以确保我具有系统级依赖项。因此，我还没有发现全局导入可以帮助我在实践中理解系统。
我通常将检查的内容sys放入if __name__=='__main__'检查中，然后将参数（如sys.argv[1:]）传递给main()函数。这使我可以main在sys尚未导入的上下文中使用。
def main(): print(sys.argv); if True: import sys; main();您必须包装if __name__=='__main__'一个函数以创建新的名称空间。
在大多数情况下，这样做对于保持清晰性和明智性很有用，但并非总是如此。以下是几个可能会在其他地方导入模块的情况的示例。
首先，您可以拥有一个带有以下形式的单元测试的模块：
if __name__ == '__main__':
import foo
aa = foo.xyz() # initiate something for the test其次，您可能需要在运行时有条件地导入一些不同的模块。
if [condition]:
import foo as plugin_api
else:
import bar as plugin_api
xx = plugin_api.Plugin()
[...]在其他情况下，您可能会将导入放置在代码的其他部分中。
当函数被调用为零或一次时，第一种变体的确比第二种变体更有效。但是，在第二次及其后的调用中，“导入每个调用”方法实际上效率较低。请参阅此链接以获取延迟加载技术，该技术通过执行“延迟导入”结合了两种方法的优点。
但是，除了效率之外，还有其他原因导致您可能会偏爱一个。一种方法是使阅读该模块相关代码的人更加清楚。它们还具有非常不同的故障特征-如果没有“ datetime”模块，第一个将在加载时失败，而第二个在调用该方法之前不会失败。
补充说明：在IronPython中，导入可能比CPython中昂贵得多，因为代码基本上是在导入时进行编译的。
我不会担心过多地预先加载模块的效率。模块占用的内存不会很大（假设它足够模块化），启动成本可以忽略不计。
在大多数情况下，您希望将模块加载到源文件的顶部。对于阅读您的代码的人来说，它更容易分辨出哪个功能或对象来自哪个模块。
将模块导入代码中其他位置的一个很好的理由是，如果该模块在调试语句中使用过。
例如：
do_something_with_x(x)我可以使用以下命令调试它：
from pprint import pprint
pprint(x)
do_something_with_x(x)当然，将模块导入代码中其他位置的另一个原因是是否需要动态导入它们。这是因为您几乎别无选择。
我不会担心过多地预先加载模块的效率。模块占用的内存不会很大（假设它足够模块化），启动成本可以忽略不计。
这是一个折衷，只有程序员才能决定进行。
情况1通过在需要之前不导入datetime模块（并进行可能需要的任何初始化）来节省一些内存和启动时间。请注意，“仅在调用时”执行导入也意味着“在调用时每次”进行导入，因此第一个调用之后的每个调用仍会产生执行导入的额外开销。
情况2通过预先导入datetime来节省一些执行时间和延迟，以便not_often_drawn（）在被调用时将更快地返回，并且还不会在每次调用时都导致导入开销。
除了效率外，如果import语句在...前面，则更容易在前面看到模块依赖性。将它们隐藏在代码中会使您更难于找到所需的模块。
就个人而言，除了单元测试之类的东西外，我通常都遵循PEP，因此我不希望总是加载它，因为我知道除了测试代码之外不会使用它们。
sys.modules仅通过查找本地名称而不是全局名称所节省的费用就可以轻松抵消查找模块的成本。
这是一个示例，其中所有导入都位于最顶部（这是我唯一需要这样做的时间）。我希望能够在Un * x和Windows上终止子进程。
import os
# ...
try:
kill = os.kill # will raise AttributeError on Windows
from signal import SIGTERM
def terminate(process):
kill(process.pid, SIGTERM)
except (AttributeError, ImportError):
try:
from win32api import TerminateProcess # use win32api if available
def terminate(process):
TerminateProcess(int(process._handle), -1)
except ImportError:
def terminate(process):
raise NotImplementedError # define a dummy function（评论：约翰·米利金说的话。）
就像许多其他优化一样，您会牺牲一些可读性来提高速度。如John所述，如果您完成了概要分析作业，并且发现这是一项非常有用的更改，并且您需要额外的速度，则可以继续进行。在所有其他进口商品上加上注释可能会很好：
from foo import bar
from baz import qux
# Note: datetime is imported in SomeClass below模块初始化仅发生一次-在首次导入时。如果有问题的模块来自标准库，那么您也可能会从程序中的其他模块导入它。对于像日期时间一样普遍的模块，它也可能是许多其他标准库的依赖项。由于模块初始化已经发生，因此import语句的花费很少。此时，它所做的全部工作就是将现有模块对象绑定到本地范围。
将该信息与用于可读性的参数相结合，我想说最好在模块范围内使用import语句。
只是为了完成萌的答案和原始问题：
当我们不得不处理循环依赖时，我们可以做一些“技巧”。假设我们正在与模块的工作a.py，并b.py包含x()和B y()分别。然后：
from imports模块底部的之一。from imports实际上需要导入的函数或方法的内部之一（这并不总是可能的，因为您可以在多个地方使用它）。from imports为如下所示的导入：import a因此，总结一下。如果您不是在处理循环依赖关系，而是采取某种技巧来避免它们，那么最好将所有导入内容放在顶部，因为在此问题的其他答案中已经说明了这些原因。并且，请在做“技巧”时添加评论，我们始终欢迎您！:)
我很惊讶地没有看到已经发布的重复负载检查的实际成本数字，尽管对预期的结果有很多很好的解释。
如果您在顶部导入，则无论如何都会承受重击。这个数字很小，但是通常以毫秒为单位，而不是纳秒。
如果导入功能（S）之内，那么你只需要命中的加载，如果和当首次调用这些功能之一。正如许多人指出的那样，如果根本不发生这种情况，则可以节省加载时间。但是，如果函数被调用很多，您将遭受一次重复的打击，尽管命中率要小得多（用于检查它是否已加载；不是实际重新加载）。另一方面，正如@aaronasterling指出的那样，您还可以节省一点，因为在函数中进行导入使该函数可以使用稍快的局部变量查找来稍后标识名称（http://stackoverflow.com/questions/477096/python- import-coding-style / 4789963＃4789963）。
这是一个简单测试的结果，该测试从函数内部导入了一些东西。报告的时间（在2.3 GHz Intel Core i7上的Python 2.7.14中）显示如下（第二次调用比以后的调用更多，这似乎是一致的，尽管我不知道为什么）。
0 foo: 14429.0924 µs
1 foo: 63.8962 µs
2 foo: 10.0136 µs
3 foo: 7.1526 µs
4 foo: 7.8678 µs
0 bar: 9.0599 µs
1 bar: 6.9141 µs
2 bar: 7.1526 µs
3 bar: 7.8678 µs
4 bar: 7.1526 µs编码：
from __future__ import print_function
from time import time
def foo():
import collections
import re
import string
import math
import subprocess
return
def bar():
import collections
import re
import string
import math
import subprocess
return
t0 = time()
for i in xrange(5):
foo()
t1 = time()
print(" %2d foo: %12.4f \xC2\xB5s" % (i, (t1-t0)*1E6))
t0 = t1
for i in xrange(5):
bar()
t1 = time()
print(" %2d bar: %12.4f \xC2\xB5s" % (i, (t1-t0)*1E6))
t0 = t1我不希望提供完整的答案，因为其他人已经做得很好。当我发现在功能内部导入模块特别有用时，我只想提及一个用例。我的应用程序使用存储在特定位置的python软件包和模块作为插件。在应用程序启动期间，应用程序遍历该位置的所有模块并将其导入，然后在模块内部查找，如果找到了插件的安装点（在我的情况下，它是具有唯一标识的某些基类的子类ID）将其注册。插件的数量很大（现在有几十个，但将来可能有数百个），每个插件很少使用。在应用程序启动过程中，在我的插件模块顶部添加了第三方库，这会带来一些损失。尤其是某些第三方库的导入非常繁重（例如，密谋导入甚至尝试连接到Internet并下载一些内容，这些内容在启动时增加了大约一秒钟的时间）。通过优化插件中的导入（仅在使用它们的函数中调用它们），我设法将启动时间从10秒缩短到大约2秒。对于我的用户而言，这是一个很大的差异。
所以我的答案是不，不要总是将导入放在模块的顶部。
通过将变量/局部作用域导入函数内部，可以提高性能。这取决于函数中导入事物的用法。如果要循环很多次并访问模块全局对象，则将其作为本地导入可以有所帮助。
X=10
Y=11
Z=12
def add(i):
i = i + 10from test import add, X, Y, Z
def callme():
x=X
y=Y
z=Z
ladd=add
for i in range(100000000):
ladd(i)
x+y+z
callme()from test import add, X, Y, Z
def callme():
for i in range(100000000):
add(i)
X+Y+Z
callme()在Linux上使用一段时间显示收益很小
/usr/bin/time -f "\t%E real,\t%U user,\t%S sys" python run.py
0:17.80 real, 17.77 user, 0.01 sys
/tmp/test$ /usr/bin/time -f "\t%E real,\t%U user,\t%S sys" python runlocal.py
0:14.23 real, 14.22 user, 0.01 sys真正的是壁钟。用户是程序中的时间。sys是时候进行系统调用了。
https://docs.python.org/3.5/reference/executionmodel.html#resolution-of-names
除了启动性能外，还有一个可读性参数可用于本地化import语句。例如，在我当前的第一个python项目中，使用python行号1283到1296：
listdata.append(['tk font version', font_version])
listdata.append(['Gtk version', str(Gtk.get_major_version())+"."+
str(Gtk.get_minor_version())+"."+
str(Gtk.get_micro_version())])
import xml.etree.ElementTree as ET
xmltree = ET.parse('/usr/share/gnome/gnome-version.xml')
xmlroot = xmltree.getroot()
result = []
for child in xmlroot:
result.append(child.text)
listdata.append(['Gnome version', result[0]+"."+result[1]+"."+
result[2]+" "+result[3]])如果该import语句位于文件的顶部，则必须向上滚动很长一段距离，或者按Home，以查找内容ET。然后，我将不得不导航回到第1283行以继续阅读代码。
确实，即使 import语句位于函数（或类）的顶部（如许多语句所放置的那样），也需要向上和向下分页。
显示Gnome版本号的操作很少，因此import文件顶部会引入不必要的启动延迟。
这是一个有趣的讨论。像许多其他人一样，我什至从未考虑过这个话题。由于想要在我的一个库中使用Django ORM，我不得不在函数中具有导入功能。我不得不打电话django.setup()在导入模型类之前，我，因为这是文件的顶部，由于IoC注入器的构造，它被拖到了完全非Django的库代码中。
我有点四处乱窜，最后将django.setup()in放在单例构造函数中，并将相关的导入放在每个类方法的顶部。现在，这种方法工作正常，但是由于进口商品不在顶部而使我感到不安，而且我也开始担心进口商品的额外时间。然后我来到这里，以极大的兴趣阅读了大家对此的看法。
我有很长的C ++背景，现在使用Python / Cython。我对此的看法是，为什么不将导入内容放入函数中，除非它导致概要分析的瓶颈。这就像在需要变量之前为变量声明空间。麻烦的是，我有数千行代码，所有导入都在顶部！所以我想从现在开始，当我经过并有时间时，在这里和那里更改奇数文件。