我应该使用`import os.path`还是`import os`？

Question

根据官方文档，os.path是一个模块。因此，导入它的首选方式是什么？

# Should I always import it explicitly?
import os.path

要么…

# Is importing os enough?
import os

请不要回答“os为我导入作品”。我知道，它现在也对我有效（自python 2.6起）。我想知道的是有关此问题的任何官方建议。因此，如果您回答此问题，请
发表您的参考资料 。

Answer 1

os.path以一种有趣的方式工作。看起来os应该是一个带有子模块的程序包path，但实际上os是一个普通的模块，sys.modules可以注入魔力os.path。这是发生了什么：

• Python启动时，会将一堆模块加载到中sys.modules。它们没有绑定到脚本中的任何名称，但是以某种方式导入它们时，您可以访问已创建的模块。

  • sys.modules是在其中缓存模块的命令。导入模块时，如果它已经被导入到某处，它将获取实例存储在中sys.modules。
  • os是Python启动时加载的模块之一。它将其path属性分配给特定于os的路径模块。

• 它会注入，sys.modules['os.path'] = path以便您可以像对待import os.path子模块一样执行“ ”。

我倾向于将其os.path看作 是我要使用 的os模块，而不是 模块中的 任何东西 ，因此，即使它 实际上
不是被称为包的子模块os，我也可以将其导入，就像 我一直那样import os.path。这与os.path记录方式一致。

顺便说一句，我认为这种结构导致很多Python程序员对模块和包以及代码组织产生了早期的困惑。这确实有两个原因

1. 如果您将其os视为一个包并且知道可以执行import os并有权访问该子模块os.path，则稍后可能会感到惊讶，因为您无法执行import twisted并且twisted.spread无需导入就可以自动访问。

2. 令人困惑的是，这os.name是正常现象，字符串和os.path模块。我总是用空__init__.py文件来构造我的包，以便在同一级别上我总是有一种类型的东西：模块/包或其他东西。几个大型的Python项目都采用这种方法，这往往会使代码更加结构化。