大型项目中为了维护方便,通常使用模块化开发,模块化的过程中,就会涉及到各种包或者模块的相互导入,即使是对于有多个项目的Python开发者来说, import 也会让人困惑!本文带你深入了解python中 import 的内在机制,从而避免import导入引发的异常。 概念模块(module)任何 .py 文件都可以称为模块 包(package)可以将多个模块放入一个包中,就像电脑中的文件夹,但与文件夹的区别是,package包含 __init__.py 文件 Python import 的搜索路径当我们执行 python xx.py 时,python是如何帮我们正确定位包所在的目录呢?其实系统是按照以下顺序来寻找的: 1.系统内置模块,比如os, sys模块2.入口文件所在的目录,比如main.py所在的目录3.Python环境变量,也就是我们平时pip install后的包所在的目录,如Anaconda下的site-packages目录 在Python中,如果遇到了import错误,我们可以通过以下命令查看搜索路径: import sysprint(sys.path) 结果:
可以看到,其中第一个目录是我们运行的文件所在目录,其它都是Python环境变量中的目录 执行 python xx.py 发生了什么?直接被Python解释器运行的文件,称之为程序的 入口文件 ,在Python中,入口文件有且仅有一个 我们经常使用以下语句: # in main.pyif __name__=='__main__': run() __name__=='__main__' 这个语句就是检测当前脚本是否被当作入口文件使用,如果被当做入口文件使用,那么就运行 if __name__=='__main__': 下面的代码块,如果只是当做模块被其他的模块 import 进去使用,那就不应该运行这部分代码块。 因此,判断一个文件是否被python解释器当做入口文件对待,是可以打印脚本的 __name__ 变量的。
入口文件和 import 路径有什么关系呢?如果我们把 xx.py 当做入口文件,那么Python解释器,就会将 xx.py 所在的目录,加入到sys.path中,作为import时搜索的根目录。简言之,你用 python filename.py 执行哪个文件,Python解释器就会将哪个文件所在目录加入 import 的搜索目录。 新问题:在模块化的项目中,如何让Python解释器搜索到所有的模块呢?这引入了一个项目结构合理性的问题: 入口文件的目录层级应该是顶层的 ,也就是入口文件目录层级不应该低于任何模块或者包,一个常见的目录结构通常如下: $ tree./project├── package│ ├── __init__.py│ ├── sub_pkg1│ │ ├── __init__.py│ │ ├── module_X.py│ │ └── module_Y.py│ └── sub_pkg2│ ├── __init__.py│ └── module_Z.py└── main.py(入口文件) 如果我们执行 python main.py ,那么main.py就会被当做入口文件,所在目录 project 就会被加入import的搜索路径,那么我们将能够搜索 package1 和 package2 中的模块;现在假设我们直接运行 python module_X.py ,此时入口文件变成了 module_X.py ,那么我们 import 搜索的根目录为 sub_pkg1 ,当我们试图去 import sub_pkg2 中的文件时,就会引发异常。 上述问题引入了一个准则:除了入口文件之外,其他文件都不应该通过python xx.py来运行,那如果我们想运行某个模块怎么办?答案是:通过 python -m sub_pkg1.module_X 来运行! python -m 的意思是将module当做模块来运行,同时 sub_pkg1.module_X 是导入路径,这样子就不会找不到模块了。 上述解决方案引入一个比较好的实践:如果在一个大型项目中,你经常使用 cd 命令跳转到各种不同层级的目录中 Python xx.py 运行某个模块,那你可能得尝试使用 Python -m 了,也就是我们最好在项目的根目录下完成所有的模块的测试。当然,完善的项目,应该有专门的测试目录如 tests , 这个以后有机会再讲。 Python中的相对导入和绝对导入在Python中,存在相对导入和绝对导入两种import机制,但无论是绝对导入还是相对导入,都需要一个参照物,不然「绝对」与「相对」的概念就无从谈起。绝对导入的参照物是项目的根文件夹,相对导入参照物是当前模块,当我们使用相对导入时,需要给出相对于当前模块,想导入模块所在的位置。
相对导入可以避免硬编码带来的维护问题,例如我们改了某一顶层包的名字,那么其子包所有的导入就都不能用了。除非我们手动修改顶层包名。 但是存在相对导入语句的模块,不能直接使用 python xx.py 的方式运行,否则会有异常: ValueError: Attempted relative import in non-package ·如果是绝对导入,一个模块只能导入自身的子模块或和它的顶层模块同级别的模块及其子模块·如果是相对导入,一个模块必须有 包结构 (意味着有 __init__.py )且只能导入它的顶层模块内部的模块 所以,如果一个模块被直接运行,Python会将该模块当做 顶层模块(top level) ,不再当做一个包来对待,因此不存在层次结构,所以找不到其他的相对路径,所以如果直接运行python xx.py ,而xx.py有相对导入就会报错 看下面例子:
module_X.py from . import module_Yprint 'X __name__', __name__ module_Y.py
当我们直接运行 python sub_pkg1/module_X.py 的时候,会报错 ValueError: Attempted relative import in non-package 当我们这样运行的时候 python -m sub_pkg1.module_X , 才能正常运行
为什么会这样?简单地说,直接运行 .py 文件和 import 这个文件有很大区别。Python 解释器判断一个 py 文件属于哪个 package 时并不完全由该文件所在的文件夹决定。它还取决于这个文件是如何 load 进来的( 直接运行 or import )。 有两种方式加载一个 py 文件: ·作为 top-level 脚本 作为 top-level 脚本指的是直接运行脚本,比如 python xx.py。有且只能有一个 top-level 脚本,就是最开始执行的那个(比如 python xx.py 中的 xx.py)。·作为 module 作为 module 是指,执行 python -m xx,或者在其它 py 文件中用 import 语句来加载,那么它就会被当作一个 module。 当一个 py 文件被加载之后,它会被赋予一个名字,保存在 __name__ 属性中。如果是 top-level 脚本,那么名字就是 __main__ 。如果是作为 module,名字就是把它所在的 packages/subpackages 和文件名用 . 连接起来。 例如,moduleX 被 import 进来,它的名字就是 所以上面的 module_X 的 __name__ 是 __main__ , 因为他是直接运行的, module_Y 的 __name__ 是 sub_pkg1.module_Y ,因为他是被import 来使用的。 常见几种import需求module_X.py # module_X导入module_Y# 相对导入from . import module_Y# 绝对导入from package.sub_pkg1 import module_Y module_X.py
main.py # main.py导入module_Yfrom package.sub_pkg1 import module_Y 特别需要注意的是,虽然上述模块导入路径是对的,除了 main.py 之外,都不可以通过 python xx.py 的方式运行,而是通过前面讨论过个 python -m 方式运行。 相对导入和绝对导入的优缺点相对导入可以避免硬编码,对于包的维护是友好的。其缺点是可读性较差,让人很难清楚地了解到资源所在的位置。 绝对路径导入由于其直观往往是大家的首选。只要看一下导入语句你就能知道资源是从什么位置导入的。再者,就算当前import语句的位置发生了变化,此绝对路径导入的资源依然有效。实际上,官方也推荐使用绝对路径导入。 《Python之禅》中提到: 明确 由于 隐晦 纵观一些优秀的开源项目,绝对导入的使用也是更为普遍的。我个人通常以绝对导入为主,相对导入为辅,只会在同一个模块层级中使用一些相对导入,如: from .fool import spam ,很少会使用 from ...fool import spam 这样让人迷惑的相对导入。 解决import错误的调试思路1.区分是文件夹还是包(有无 __init__.py )? 2.非入口文件是否是使用python -m运行的? 3.入口文件的层级,是否高于任何包或者模块? |
|