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()
当前回答
这是一个引人入胜的讨论。和许多人一样，我从未考虑过这个话题。我不得不在函数中导入，因为我想在我的一个库中使用Django ORM。在导入我的模型类之前，我不得不调用django.setup()，因为这是在文件的顶部，它被拖到完全非django库代码中，因为IoC注入器结构。
我稍微改了一下，最后把django.setup()放在了单例构造函数中，并把相关的导入放在了每个类方法的顶部。现在这运行得很好，但让我感到不安，因为导入不在顶部，而且我开始担心导入的额外时间。然后我来到这里，怀着极大的兴趣阅读了大家对此的看法。
我有很长的c++背景，现在使用Python/Cython。我对此的看法是，为什么不把导入放在函数中，除非它会导致一个概要瓶颈。这就像在你需要变量之前为它们声明空间一样。问题是我有数千行代码，所有的导入都在顶部!所以我想从现在开始，当我有时间的时候，我会在这里和那里改变奇怪的文件。
其他回答
当函数被调用0次或1次时，第一种变体确实比第二种更有效。然而，对于第二次和后续调用，“导入每个调用”方法实际上效率较低。请参阅此链接，了解一种通过“惰性导入”将两种方法的优点结合起来的惰性加载技术。
但除了效率之外，还有其他原因可以解释为什么你会更喜欢其中一种。一种方法是让阅读代码的人更清楚地了解这个模块所具有的依赖关系。它们也有非常不同的失败特征——如果没有“datetime”模块，第一个将在加载时失败，而第二个直到方法被调用才会失败。
补充说明:在IronPython中，导入可能比在CPython中要昂贵一些，因为代码基本上是在导入时被编译的。
我很惊讶没有看到重复负载检查的实际成本数字，尽管有很多很好的解释。
如果你在顶部导入，不管发生什么，你都要加载命中。这非常小，但通常是毫秒级，而不是纳秒级。
If you import within a function(s), then you only take the hit for loading if and when one of those functions is first called. As many have pointed out, if that doesn't happen at all, you save the load time. But if the function(s) get called a lot, you take a repeated though much smaller hit (for checking that it has been loaded; not for actually re-loading). On the other hand, as @aaronasterling pointed out you also save a little because importing within a function lets the function use slightly-faster local variable lookups to identify the name later (http://stackoverflow.com/questions/477096/python-import-coding-style/4789963#4789963).
下面是一个简单测试的结果，该测试从函数内部导入了一些内容。报告的时间(在2.3 GHz Intel Core i7上的Python 2.7.14中)如下所示(第2个调用比后面的调用多似乎是一致的，尽管我不知道为什么)。
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
虽然PEP鼓励在模块顶部导入，但在其他级别导入并不会出错。这表明进口应该在顶部，但也有例外。
在使用模块时加载模块是一种微优化。导入缓慢的代码可以在以后进行优化，如果这会产生相当大的差异的话。
不过，您可以在尽可能靠近顶部的位置引入标志，以便有条件地导入，允许用户使用配置导入所需的模块，同时仍然立即导入所有内容。
尽快导入意味着如果任何导入(或导入的导入)缺失或有语法错误，程序将失败。如果所有导入都发生在所有模块的顶部，则python分两步工作。编译。运行。
内置模块可以在任何导入它们的地方工作，因为它们设计得很好。您编写的模块应该是相同的。将导入移动到顶部或它们的第一次使用位置有助于确保没有副作用，并且代码正在注入依赖项。
无论您是否将导入放在顶部，当导入放在顶部时，代码都应该仍然可以工作。所以从立即导入开始，然后根据需要进行优化。
我不太担心预先加载模块的效率。模块占用的内存不会很大(假设它足够模块化)，启动成本可以忽略不计。
在大多数情况下，您希望在源文件的顶部加载模块。对于阅读代码的人来说，它可以更容易地区分哪个函数或对象来自哪个模块。
在代码的其他地方导入模块的一个很好的理由是，如果它在调试语句中使用。
例如:
do_something_with_x(x)
我可以用:
from pprint import pprint
pprint(x)
do_something_with_x(x)
当然，在代码的其他地方导入模块的另一个原因是，如果您需要动态导入它们。这是因为你几乎没有任何选择。
我不太担心预先加载模块的效率。模块占用的内存不会很大(假设它足够模块化)，启动成本可以忽略不计。
大多数情况下，这对于清晰和明智的做法是有用的，但并不总是如此。下面是模块导入可能存在于其他地方的两个例子。
首先，你可以有一个这样的单元测试模块:
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()
[...]
在其他情况下，您可能会在代码的其他部分导入。
