在python项目开发中，我们经常会将相关的类、函数或变量组织在一个独立的模块文件中，例如lib.py。当其他脚本需要使用这些自定义类型时，通常会采用import lib的方式进行导入。然而，这种导入方式要求我们在每次引用模块内的对象时，都必须加上模块名前缀，例如lib.vec3。对于追求代码简洁性和与内置类型一致性体验的开发者而言，这种冗余的模块前缀可能会降低代码的可读性与编写效率。
常见的导入方式及其局限性
假设我们有一个名为lib.py的文件，其中定义了一个三维向量类vec3：
# lib.py
class vec3:
def __init__(self, x: float, y: float, z: float):
self.x = x
self.y = y
self.z = z
def __repr__(self):
return f"vec3({self.x}, {self.y}, {self.z})"在另一个主脚本中，如果使用import lib进行导入，则必须通过lib.vec3来实例化对象：
# main_script.py (使用 import lib 方式) import lib # 实例化 vec3 类，需要加上模块前缀 v1 = lib.vec3(1.0, 2.0, 3.0) print(v1) # 输出: vec3(1.0, 2.0, 3.0)
这种方式虽然清晰地指明了vec3的来源，但在频繁使用时，重复的lib.前缀会显得有些繁琐。
解决方案一：精确导入指定对象
Python提供了from module import object_name的语法，允许我们从模块中直接导入指定的类、函数或变量到当前命名空间。这样，我们就可以像使用本地定义的对象一样，直接通过其名称进行访问，而无需模块前缀。
立即学习“Python免费学习笔记（深入）”；
# main_script.py (使用 from lib import vec3 方式) from lib import vec3 # 直接实例化 vec3 类，无需模块前缀 v2 = vec3(4.0, 5.0, 6.0) print(v2) # 输出: vec3(4.0, 5.0, 6.0)
优点：
- 代码简洁： 消除了冗余的模块前缀，提高了代码的可读性。
- 明确性： 仅导入所需的对象，避免了不必要的命名空间污染。
- 避免命名冲突： 如果模块中有多个对象，通过精确导入可以避免与当前脚本中同名对象的冲突。
注意事项：
本文档主要讲述的是Python之模块学习；python是由一系列的模块组成的，每个模块就是一个py为后缀的文件，同时模块也是一个命名空间，从而避免了变量名称冲突的问题。模块我们就可以理解为lib库，如果需要使用某个模块中的函数或对象，则要导入这个模块才可以使用，除了系统默认的模块（内置函数）不需要导入外。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
- 如果需要导入模块中的多个对象，可以通过逗号分隔：from lib import vec3, another_class, some_function。
- 如果导入的对象名称与当前脚本中已有的名称冲突，可以使用as关键字进行重命名：from lib import vec3 as Vector3D。
解决方案二：批量导入所有公共对象（通配符导入）
另一种方式是使用from module import *，它会将模块中所有公共对象（即名称不以下划线开头的对象）导入到当前命名空间。这种方式提供了最大的便利性，允许开发者直接使用模块内的所有对象。
# lib.py (假设还定义了另一个类)
class vec3:
def __init__(self, x: float, y: float, z: float):
self.x = x
self.y = y
self.z = z
def __repr__(self):
return f"vec3({self.x}, {self.y}, {self.z})"
class Color:
def __init__(self, r, g, b):
self.r, self.g, self.b = r, g, b
def __repr__(self):
return f"Color({self.r}, {self.g}, {self.b})"
# main_script.py (使用 from lib import * 方式)
from lib import *
# 直接使用 vec3 和 Color，无需模块前缀
v3 = vec3(7.0, 8.0, 9.0)
c1 = Color(255, 0, 0)
print(v3) # 输出: vec3(7.0, 8.0, 9.0)
print(c1) # 输出: Color(255, 0, 0)优点：
- 极致便捷： 无需逐一列出要导入的对象，尤其适用于需要导入模块中绝大多数内容的情况。
潜在风险与最佳实践： 尽管from module import *看起来非常方便，但在实际的生产环境中，它通常被视为一种不推荐的做法，原因如下：
- 命名空间污染： 它会将模块中所有公共名称都导入到当前命名空间，可能覆盖当前脚本中已有的同名变量、函数或类，导致意料之外的行为和难以调试的错误。
- 代码可读性降低： 当代码中出现一个名称时，很难直观地判断它究竟是来自哪个模块，或者它是否是一个本地定义的对象。这增加了代码理解和维护的难度。
- 调试困难： 当出现命名冲突或对象行为异常时，追踪其来源变得复杂。
- 模块演变风险： 随着模块的更新，新添加的公共对象可能会无意中与你的代码产生命名冲突。
因此，from module import *通常仅在以下特定场景中谨慎使用：
- 交互式解释器环境： 在进行快速原型开发或测试时，为了方便可以临时使用。
- __init__.py文件： 在Python包的__init__.py文件中，为了将子模块中的特定接口暴露为包的直接成员，有时会使用from .sub_module import *。
- 特定框架或库的设计： 某些库（如Tkinter）会推荐使用from tkinter import *以简化GUI组件的访问，但即便如此，也应了解其潜在影响。
总结
在Python中，为了提高代码的简洁性和可读性，同时避免模块前缀的冗余，我们可以选择from module import ClassName或from module import *这两种导入方式。
- 推荐使用from module import ClassName： 这种方式提供了最佳的平衡，既能直接访问对象，又保持了命名空间的清晰和代码的明确性。它有助于避免命名冲突，并使代码更易于理解和维护。
- *谨慎使用`from module import `：** 尽管它提供了极大的便利，但其带来的命名空间污染和可读性下降的风险通常大于其带来的好处。除非在非常明确且受控的环境下，否则应尽量避免在生产代码中使用。
选择合适的导入策略是编写高质量Python代码的关键一环。理解不同导入方式的优缺点，并根据项目需求和团队规范做出明智的选择，将有助于构建更健壮、更易于维护的应用程序。
