有很多答案，但没有一个提到测试(使用unittest或pytest)。

博士tl;

对外部模块使用import foo来简化测试。

艰难的方式

从模块中单独导入类/函数(从foo import bar中)会使红绿重构周期变得冗长乏味。例如，如果我的文件看起来像

# my_module.py

from foo import bar


class Thing:
    def do_thing(self):
        bar('do a thing')

我的测试是

# test_my_module.py

from unittest.mock import patch
import my_module


patch.object(my_module, 'bar')
def test_do_thing(mock_bar):
    my_module.Thing().do_thing()
    mock_bar.assert_called_with('do a thing')

乍一看，这似乎很棒。但是如果我想在不同的文件中实现Thing类会发生什么呢?我的结构将不得不像这样改变……

# my_module.py

from tools import Thing


def do_thing():
    Thing().do_thing()


# tools.py

from foo import bar


class Thing:
    def do_thing(self):
        bar('do a thing')


# test_my_module.py

from unittest.mock import patch
import my_module
import tools  # Had to import implementation file...


patch.object(tools, 'bar')  # Changed patch
def test_do_thing(mock_bar):
    my_module.do_thing()  # Changed test (expected)
    mock_bar.assert_called_with('do a thing')

不幸的是，由于我使用from foo import bar，我需要更新我的补丁来引用工具模块。从本质上讲，由于我的测试对实现了解太多，因此要进行这个重构，需要更改的内容要比预期的多得多。

更好的方法

使用import foo，我的测试可以忽略模块是如何实现的，而只是对整个模块打补丁。

# my_module.py

from tools import Thing


def do_thing():
    Thing().do_thing()


# tools.py

import foo


class Thing:
    def do_thing(self):
        foo.bar('do a thing')  # Specify 'bar' is from 'foo' module


# test_my_module.py

from unittest.mock import patch
import my_module


patch('foo')  # Patch entire foo module
def test_do_thing(mock_foo):
    my_module.do_thing()  # Changed test (expected)
    mock_foo.bar.assert_called_with('do a thing')

测试知道的实现细节越少越好。这样，如果您提出了更好的解决方案(使用类而不是函数，使用额外的文件来分离思想，等等)，那么在您的测试中需要更改的内容就会更少，以适应重构。

因为很多人都在这里回答，但我只是尽力了:)

当你不知道你必须从模块中导入哪个项时，导入模块是最好的。通过这种方式，当问题出现时可能很难进行调试，因为 你不知道哪个项目有问题。 Form module import <foo>是最好的，当你知道你需要导入哪个项目时，它也有助于根据你的需要导入特定的项目。使用这种方式调试可能很容易，因为您知道导入了哪个项。

补充一下人们关于from x import *的说法:除了使名称的来源更加困难之外，这还会使Pylint等代码检查器无法使用。它们将报告这些名称为未定义的变量。

我自己的答案主要取决于首先，我将使用多少不同的模块。如果我只打算用一两个，我会经常用from…import，因为它在文件的其余部分减少了击键，但如果我要使用许多不同的模块，我更喜欢只使用import，因为这意味着每个模块引用都是自文档化的。我可以看到每个符号的来源，而不需要到处寻找。

通常我更喜欢简单导入的自文档风格，只更改from..当我必须输入模块名的次数增加到10到20次时，即使只有一个模块被导入。

有一些内置模块主要包含裸函数(base64, math, os, shutil, sys, time，…)，将这些裸函数绑定到某个名称空间绝对是一个很好的实践，从而提高代码的可读性。想想看，如果没有命名空间，要理解这些函数的含义是多么困难:

copysign(foo, bar)
monotonic()
copystat(foo, bar)

当它们被绑定到某个模块时:

math.copysign(foo, bar)
time.monotonic()
shutil.copystat(foo, bar)

有时你甚至需要命名空间来避免不同模块之间的冲突(json. xml)。Load vs. pickle.load) 另一方面，有些模块包含大部分类(configparser, datetime, tempfile, zipfile，…)，其中许多模块的类名不言自明:

configparser.RawConfigParser()
datetime.DateTime()
email.message.EmailMessage()
tempfile.NamedTemporaryFile()
zipfile.ZipFile()

因此，在代码中使用这些类和额外的模块名称空间是增加了一些新信息还是只是延长了代码，可能会有争论。

我个人总是用

from package.subpackage.subsubpackage import module

然后访问所有

module.function
module.modulevar

等。原因是，与此同时，您可以进行简短的调用，并且可以清楚地定义每个例程的模块名称空间，如果您必须在源代码中搜索给定模块的使用情况，这是非常有用的。

不用说，不要使用import *，因为它会污染您的命名空间，并且它不会告诉您给定函数来自何处(来自哪个模块)

当然，如果在两个不同的包中对两个不同的模块使用相同的模块名，您可能会遇到麻烦，例如

from package1.subpackage import module
from package2.subpackage import module

在这种情况下，您当然会遇到麻烦，但是强烈地暗示您的包布局有缺陷，您必须重新考虑它。