>>> import os
>>> help(os.path)
...
Instead of importing this module directly, import os and refer to
this module as os.path. The "os.path" name is an alias for this
module on Posix systems; on other systems (e.g. Mac, Windows),
os.path provides the same operations in a manner specific to that
platform, and is an alias to another module (e.g. macpath, ntpath).
...
根据Tim Peters的PEP-20,“显式优于隐式”和“可读性计数”。如果
os
模块所需的全部内容都在os.path
下,那么import os.path
将更加明确,并让其他人知道您真正关心的是什么。同样,PEP-20也说“简单胜于复杂”,所以如果您还需要更一般的
os
保护伞下的东西,那么import os
将是首选。明确答案:
import os
并使用os.path
。不要直接import os.path
。从模块本身的文档中:
os.path
的工作方式很有趣。看起来os
应该是一个带有子模块path
的包,但实际上os
是一个普通的模块,它使用sys.modules
来注入os.path
具有魔力。下面是发生的事情:当Python启动时,它会将一堆模块加载到
sys.modules
。它们没有绑定到脚本中的任何名称,但是当您以某种方式导入它们时,可以访问已经创建的模块。sys.modules
是缓存模块的dict。当您导入一个模块时,如果它已经被导入到某个地方,它将获取存储在sys.modules
中的实例。os
是Python启动时加载的模块之一。它将其path
属性分配给操作系统特定的路径模块。它注入
sys.modules['os.path'] = path
,这样就可以像子模块一样执行import os.path
。我倾向于把
os.path
看作是一个我想使用的模块,而不是os
模块中的一个东西,所以即使它不是真正的os
包的子模块,我还是像一个模块一样导入它,并且我总是这样做。这与os.path
的记录方式是一致的。顺便说一句,我认为这种结构导致了很多Python程序员对模块、包和代码组织的早期混淆。这有两个原因
如果您将
os
视为一个包,并且知道您可以执行import os
,并且可以访问子模块os.path
,那么稍后您可能会感到惊讶,因为您无法执行import twisted
,并且在不导入它的情况下自动访问twisted.spread
。令人困惑的是,
os.name
是一个普通的东西,一个字符串,os.path
是一个模块。我总是用空的__init__.py
文件来构造包,这样在同一级别上我总是有一种类型的东西:模块/包或其他东西。一些大型Python项目采用这种方法,这种方法倾向于生成更结构化的代码。相关问题 更多 >
编程相关推荐