简单地说，这都是为了方便程序员。在核心级别，它们只是导入模块的所有功能。

import module:当你使用import module时，你必须写module.method()来使用这个模块的方法。每次使用任何方法或属性时，都必须引用模块。

from module import all:当你使用from module import all而不是使用该模块的方法时，你只需要编写method()而不引用该模块。

有一些内置模块主要包含裸函数(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 x import *的说法:除了使名称的来源更加困难之外，这还会使Pylint等代码检查器无法使用。它们将报告这些名称为未定义的变量。

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

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()

导入模块——你不需要额外的努力从模块中获取另一个东西。它有缺点，如冗余输入

模块导入-更少的输入和更多的控制一个模块的项目可以访问。要使用模块中的新项，必须更新import语句。

正如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

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