正如Jan Wrobel提到的，不同导入的一个方面是导入的披露方式。

模块mymath

from math import gcd
...

使用mymath:

import mymath
mymath.gcd(30, 42)  # will work though maybe not expected

如果我导入gcd只是为了内部使用，而不向mymath的用户公开它，这可能会很不方便。我经常遇到这种情况，在大多数情况下，我想“保持我的模块干净”。

除了Jan Wrobel提出的通过使用导入数学来掩盖这一点之外，我已经开始通过使用前导下划线来隐藏导入，以避免公开:

# for instance...
from math import gcd as _gcd
# or...
import math as _math

在较大的项目中，这种“最佳实践”允许我准确地控制向后续导入公开的内容和不公开的内容。这使我的模块保持干净，并在一定规模的项目中回报。

我正在回答一个类似的问题，但在我发布之前，发帖者删除了它。这里有一个例子来说明这些区别。

Python库可以有一个或多个文件(模块)。为例子,

package1
  |-- __init__.py

or

package2
  |-- __init__.py
  |-- module1.py
  |-- module2.py

我们可以在任何基于设计需求的文件中定义python函数或类。

让我们来定义

在mylibrary1下的__init__.py中的Func1 () mylibrary2下的module2.py中的Foo()。

我们可以使用这些方法之一访问func1()

import package1

package1.func1()

or

import package1 as my

my.func1()

or

from package1 import func1

func1()

or

from package1 import *

func1()

我们可以使用以下方法之一来访问foo():

import package2.module2

package2.module2.foo()

or

import package2.module2 as mod2

mod2.foo()

or

from package2 import module2

module2.foo()

or

from package2 import module2 as mod2

mod2.foo()

or

from package2.module2 import *

foo()

有很多答案，但没有一个提到测试(使用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')

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

正如Jan Wrobel提到的，不同导入的一个方面是导入的披露方式。

模块mymath

from math import gcd
...

使用mymath:

import mymath
mymath.gcd(30, 42)  # will work though maybe not expected

如果我导入gcd只是为了内部使用，而不向mymath的用户公开它，这可能会很不方便。我经常遇到这种情况，在大多数情况下，我想“保持我的模块干净”。

除了Jan Wrobel提出的通过使用导入数学来掩盖这一点之外，我已经开始通过使用前导下划线来隐藏导入，以避免公开:

# for instance...
from math import gcd as _gcd
# or...
import math as _math

在较大的项目中，这种“最佳实践”允许我准确地控制向后续导入公开的内容和不公开的内容。这使我的模块保持干净，并在一定规模的项目中回报。

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

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

我还想补充一点。如果遇到循环导入，了解Python如何将导入的模块作为属性处理可能会很有用。

我有以下结构:

mod/
    __init__.py
    main.py
    a.py
    b.py
    c.py
    d.py

我将使用不同的导入方法从main.py导入其他模块

main.py:

import mod.a
import mod.b as b
from mod import c
import d

Dis.dis显示了两者的区别(注意模块名，a b c d):

  1           0 LOAD_CONST               0 (-1)
              3 LOAD_CONST               1 (None)
              6 IMPORT_NAME              0 (mod.a)
              9 STORE_NAME               1 (mod)

  2          12 LOAD_CONST               0 (-1)
             15 LOAD_CONST               1 (None)
             18 IMPORT_NAME              2 (b)
             21 STORE_NAME               2 (b)

  3          24 LOAD_CONST               0 (-1)
             27 LOAD_CONST               2 (('c',))
             30 IMPORT_NAME              1 (mod)
             33 IMPORT_FROM              3 (c)
             36 STORE_NAME               3 (c)
             39 POP_TOP

  4          40 LOAD_CONST               0 (-1)
             43 LOAD_CONST               1 (None)
             46 IMPORT_NAME              4 (mod.d)
             49 LOAD_ATTR                5 (d)
             52 STORE_NAME               5 (d)
             55 LOAD_CONST               1 (None)

最后它们看起来是一样的(STORE_NAME在每个例子中都是result)，但如果你需要考虑以下四个循环导入，这是值得注意的:

例二

foo/
   __init__.py
   a.py
   b.py

a.py:
import foo.b 

b.py:
import foo.a

>>> import foo.a
>>>

这是

example2

bar/
   __init__.py
   a.py
   b.py

a.py:
import bar.b as b

b.py:
import bar.a as a

>>> import bar.a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "bar\a.py", line 1, in <module>
    import bar.b as b
  File "bar\b.py", line 1, in <module>
    import bar.a as a
AttributeError: 'module' object has no attribute 'a'

没说

青年们

baz/
   __init__.py
   a.py
   b.py

a.py:
from baz import b

b.py:
from baz import a

>>> import baz.a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "baz\a.py", line 1, in <module>
    from baz import b
  File "baz\b.py", line 1, in <module>
    from baz import a
ImportError: cannot import name a

类似的问题……但显然，从x导入y并不等于从y导入x

example4

qux/
   __init__.py
   a.py
   b.py

a.py:
import b 

b.py:
import a

>>> import qux.a
>>>

这个也可以