PEP 8规定:
导入总是放在文件的顶部，就在任何模块注释和文档字符串之后，在模块全局变量和常量之前。
然而，如果我导入的类/方法/函数只在很少的情况下使用，那么在需要时进行导入肯定会更有效吗?
这不是:
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()
当前回答
I do not aspire to provide complete answer, because others have already done this very well. I just want to mention one use case when I find especially useful to import modules inside functions. My application uses python packages and modules stored in certain location as plugins. During application startup, the application walks through all the modules in the location and imports them, then it looks inside the modules and if it finds some mounting points for the plugins (in my case it is a subclass of a certain base class having a unique ID) it registers them. The number of plugins is large (now dozens, but maybe hundreds in the future) and each of them is used quite rarely. Having imports of third party libraries at the top of my plugin modules was a bit penalty during application startup. Especially some thirdparty libraries are heavy to import (e.g. import of plotly even tries to connect to internet and download something which was adding about one second to startup). By optimizing imports (calling them only in the functions where they are used) in the plugins I managed to shrink the startup from 10 seconds to some 2 seconds. That is a big difference for my users.
所以我的答案是否定的，不要总是把导入放在模块的顶部。
其他回答
大多数情况下，这对于清晰和明智的做法是有用的，但并不总是如此。下面是模块导入可能存在于其他地方的两个例子。
首先，你可以有一个这样的单元测试模块:
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()
[...]
在其他情况下，您可能会在代码的其他部分导入。
模块导入非常快，但不是即时的。这意味着:
将导入放在模块的顶部是可以的，因为这是一个微不足道的成本，只需要支付一次。 将导入放在函数中会导致对该函数的调用花费更长的时间。
所以如果你关心效率，把进口放在最上面。只有在分析显示有帮助的情况下，才将它们移动到函数中(您进行了分析，以查看哪里可以最好地提高性能，对吗??)
我所见过的执行惰性导入的最佳理由是:
可选的库支持。如果您的代码有多个使用不同库的路径，如果没有安装可选库，请不要中断。 在插件的__init__.py中，该插件可能被导入，但实际上没有使用。例如Bazaar插件，它们使用bzrlib的惰性加载框架。
下面是一个示例，其中所有导入都位于最顶部(这是我唯一一次需要这样做)。我希望能够在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
(回顾:约翰·米利金所说。)
这是一个只有程序员才能决定的权衡。
Case 1在需要时才导入datetime模块(并进行任何可能需要的初始化)，从而节省了一些内存和启动时间。请注意，“仅在被调用时”导入也意味着“每次被调用时”导入，因此第一次调用之后的每个调用仍然会产生执行导入的额外开销。
情况2通过提前导入datetime来节省一些执行时间和延迟，这样在调用not_often_called()时就会更快地返回，而且也不会在每次调用时都产生导入的开销。
除了效率，如果import语句是…前面。将它们隐藏在代码中会使查找某个组件所依赖的模块变得更加困难。
就我个人而言，我通常遵循PEP，除了单元测试之类的东西，我不希望总是加载这些东西，因为我知道除了测试代码之外，它们不会被使用。
在函数中导入变量/局部作用域可以提高性能。这取决于函数中导入对象的使用情况。如果你多次循环并访问一个模块全局对象，将它导入为本地会有帮助。
test.py
X=10
Y=11
Z=12
def add(i):
i = i + 10
runlocal.py
from 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()
run.py
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
