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()
当前回答
我采用了将所有导入放在使用它们的函数中，而不是放在模块的顶部的做法。
这样做的好处是能够更可靠地进行重构。当我将一个函数从一个模块移动到另一个模块时，我知道该函数将继续工作，并且保留所有遗留的测试。如果我将导入放在模块的顶部，当我移动一个函数时，我发现我最终要花费大量时间来完成新模块的导入并使其最小化。重构IDE可能会让这一点变得无关紧要。
正如在其他地方提到的那样，有一个速度惩罚。我在我的应用程序中测量了这一点，发现它对我的目的来说是微不足道的。
不需要搜索(例如grep)就能看到所有模块依赖关系也是很好的。然而，我关心模块依赖关系的原因通常是因为我正在安装、重构或移动由多个文件组成的整个系统，而不仅仅是单个模块。在这种情况下，我无论如何都要执行全局搜索，以确保具有系统级依赖关系。因此，我还没有找到全局导入来帮助我在实践中理解一个系统。
我通常把sys的导入放在if __name__=='__main__'检查中，然后将参数(如sys.argv[1:])传递给main()函数。这允许我在sys未被导入的上下文中使用main。
其他回答
Curt提出了一个很好的观点:第二个版本更清晰，并且会在加载时失败，而不是在加载后失败，而且出乎意料。
通常我不担心加载模块的效率，因为它(a)非常快，(b)大多数只发生在启动时。
如果你不得不在意想不到的时候加载重量级模块，使用__import__函数动态加载它们可能更有意义，并确保捕获ImportError异常，并以合理的方式处理它们。
下面是一个示例，其中所有导入都位于最顶部(这是我唯一一次需要这样做)。我希望能够在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
(回顾:约翰·米利金所说。)
虽然PEP鼓励在模块顶部导入，但在其他级别导入并不会出错。这表明进口应该在顶部，但也有例外。
在使用模块时加载模块是一种微优化。导入缓慢的代码可以在以后进行优化，如果这会产生相当大的差异的话。
不过，您可以在尽可能靠近顶部的位置引入标志，以便有条件地导入，允许用户使用配置导入所需的模块，同时仍然立即导入所有内容。
尽快导入意味着如果任何导入(或导入的导入)缺失或有语法错误，程序将失败。如果所有导入都发生在所有模块的顶部，则python分两步工作。编译。运行。
内置模块可以在任何导入它们的地方工作，因为它们设计得很好。您编写的模块应该是相同的。将导入移动到顶部或它们的第一次使用位置有助于确保没有副作用，并且代码正在注入依赖项。
无论您是否将导入放在顶部，当导入放在顶部时，代码都应该仍然可以工作。所以从立即导入开始，然后根据需要进行优化。
我采用了将所有导入放在使用它们的函数中，而不是放在模块的顶部的做法。
这样做的好处是能够更可靠地进行重构。当我将一个函数从一个模块移动到另一个模块时，我知道该函数将继续工作，并且保留所有遗留的测试。如果我将导入放在模块的顶部，当我移动一个函数时，我发现我最终要花费大量时间来完成新模块的导入并使其最小化。重构IDE可能会让这一点变得无关紧要。
正如在其他地方提到的那样，有一个速度惩罚。我在我的应用程序中测量了这一点，发现它对我的目的来说是微不足道的。
不需要搜索(例如grep)就能看到所有模块依赖关系也是很好的。然而，我关心模块依赖关系的原因通常是因为我正在安装、重构或移动由多个文件组成的整个系统，而不仅仅是单个模块。在这种情况下，我无论如何都要执行全局搜索，以确保具有系统级依赖关系。因此，我还没有找到全局导入来帮助我在实践中理解一个系统。
我通常把sys的导入放在if __name__=='__main__'检查中，然后将参数(如sys.argv[1:])传递给main()函数。这允许我在sys未被导入的上下文中使用main。
为了完成老谋子的回答和最初的问题:
当我们不得不处理循环依赖关系时，我们可以做一些“技巧”。假设我们正在处理模块a.py和b.py，它们分别包含x()和b.y()。然后:
我们可以移动模块底部的from导入之一。 我们可以将其中一个from导入移动到实际需要导入的函数或方法中(这并不总是可行的，因为您可能从多个地方使用它)。 我们可以把其中一个import改成import，就像import a
总结一下。如果您没有处理循环依赖关系，也没有使用某种技巧来避免它们，那么最好将所有导入放在顶部，因为原因已经在这个问题的其他答案中解释过了。请在做这些“技巧”时附上评论，这总是受欢迎的!：）
