python 模块导入详解
在写python代码时常常会导入一些内置模块、第三方模块或者本人目录下写的模块。模块能够通过绝对路径或相对路径导入,既能够导入一整个包,也能够导入某个模块,还能够导入模块中的某个特定对象(类,函数或变量等)。而在一些大型的工程中,如果不通过肯定的形式治理好包的导入,则各文件之间的导入十分凌乱,极易出错。对于该工程包的内部调用者来说,如果调用的门路太深或者太乱,都很不敌对。
上面结构一个package目录,后续所有例子都依据该构造来进行解释和阐明。
我的项目根目录下有两个包,package_1和package_2;package_1下有两个包package_1_1和package_1_2;package_2下有一个包package_2_1。
在module_1_1中有一个类Cls1_1;在module_1_1_1中有一个类Cls1_1_1;其它所有module同理;所有的init文件以后为空。
import运行机制
当import XX的时候
- Python会首先从 sys.modules 门路中找是否有该模块。python 中所有加载到内存的模块都放在 sys.modules缓存 。如果加载了则只是将模块的名字退出到正在调用 import 的模块的 Local 名字空间中。
- 如果sys.modules缓存中没找到,则搜寻python的内置模块
- 如果仍没有找到,则在sys.path列表定义的门路中找该模块,如果找到则加载到以后空间。sys.path下次要就是python设置的三方包装置的门路以及当前工作的门路。
>>>sys.path ['D:\\pycharm\\PyCharm Community Edition 2021.1.1\\plugins\\python-ce\\helpers\\pydev', 'D:\\pycharm\\PyCharm Community Edition 2021.1.1\\plugins\\python-ce\\helpers\\third_party\\thriftpy', 'D:\\pycharm\\PyCharm Community Edition 2021.1.1\\plugins\\python-ce\\helpers\\pydev', 'C:\\Users\\Administrator\\anaconda\\envs\\blog\\python38.zip', 'C:\\Users\\Administrator\\anaconda\\envs\\blog\\DLLs', 'C:\\Users\\Administrator\\anaconda\\envs\\blog\\lib', 'C:\\Users\\Administrator\\anaconda\\envs\\blog', 'C:\\Users\\Administrator\\anaconda\\envs\\blog\\lib\\site-packages', #第三方包装置门路 'D:\\pycharmprojects', 'D:/pycharmprojects'##当前工作门路]
这里有一个值得注意的中央,就是pycharm 等局部IDE会主动增加以后的我的项目工作目录到sys.path中,如下面这个例子就是在pycharm中运行。而比方在控制台或者服务器上运行代码时,则不会主动增加,如:
(tensorflow) D:\>cd pycharmprojects\ (tensorflow) D:\pycharmprojects>python >>> import sys >>> import os >>> os.getcwd() 'D:\\pycharmprojects' >>> import sys >>> sys.path ['', 'C:\\Users\\Administrator\\anaconda\\envs\\tensorflow\\python36.zip', 'C:\\Users\\Administrator\\anaconda\\envs\\tensorflow\\DLLs', 'C:\\Users\\Administrator\\anaconda\\envs\\tensorflow\\lib', 'C:\\Users\\Administrator\\anaconda\\envs\\tensorflow', 'C:\\Users\\Administrator\\anaconda\\envs\\tensorflow\\lib\\site-packages',#第三方包门路 'C:\\Users\\Administrator\\anaconda\\envs\\tensorflow\\lib\\site-packages\\win32', 'C:\\Users\\Administrator\\anaconda\\envs\\tensorflow\\lib\\site-packages\\win32\\lib', 'C:\\Users\\Administrator\\anaconda\\envs\\tensorflow\\lib\\site-packages\\Pythonwin']
能够看到,在控制台中运行sys.path就没有以后的工作目录D:/pycharmprojects了;因而常常会呈现在本地IDE运行代码时没有问题,推到服务器上运行时常常报错没有XX包,可能起因之一就是在服务器上没有增加以后我的项目根目录到sys.path中。
相对导入
相对导入和绝对导入都有一个参考物,相对导入的参照基准就是最顶层包的根目录;如module_2的顶层包为package_2;module_2_1尽管在package_2_1上面,但package_2_1是在package_2上面,因而module_2_1的顶层包仍为module_2_1。有了顶层包根目录的参考,则相对导入的形式如下:
from XXX import yyy #XXX为基于该包的根目录的门路,yyy是该门路下要导入的包、模块或者对象
举例:
例子1:在module_2.py中导入module_2_1或者module_2_1中的Cls2_1
from package_2.package_2_1 import module_2_1#module_2_1的根目录为package_2 #更进一步,导入模块中的类 from package_2.package_2_1.module_2_1 import Cls2_1
留神个别说的绝对导入、相对导入都是指包内导入。但这里的包肯定是指最顶层的包,比方这里应为package_2而不是package_2_1;如果应用from package_2_1 import module_2_1
导入,也能胜利,但这里就是前面要说的绝对导入(隐式)了,因为module_2.py和package_2_1在同一目录下。
例子2:在module_1_2中导入module_1_1
#相对导入,module_1_1的顶层包根目录为package_1 from package_1.package_1_1 import module_1_1
例子3:在module_1_1中导入module_1_1_1
#module_1_1_1的顶层包根目录为package_1 >>>from package_1.package_1_1 import module_1_1#该形式没有问题 #该相对导入的门路谬误 >>>from package_1_1 import module_1_1 ModuleNotFoundError: No module named 'package_1_1'
留神和后面提到的同一个问题,尽管module_1_1和module_1_1_1都在包package_1_1下,但顶层包根目录是package_1,如果要应用相对导入,必须从package_1开始。
绝对导入
绝对导入的参照地位为以后文件所在的目录。分为隐式绝对导入和显示绝对导入。
例子1:在module_1_1_1中导入module_1_1
import module1_1 # 隐式绝对导入 from module_1_1 import Cls1_1# 隐式绝对导入 from . import module1_1#显示绝对导入,但这个在当初的python版本中会报错ImportError: attempted relative import with no known parent package;或者曾经不反对.和..这类绝对导入
例子2: 在module_1_1_1中导入module_1_2
from ..package_1_2 import module_1_2#..代表下级目录Package_1,然而该形式仍旧报错ImportError: attempted relative import with no known parent package;具体起因不确定是曾经不反对还是怎么,查了很多都未解决。
因而,同一个包目录下能够应用隐式绝对援用,跨目录最好间接都用相对援用。
导入标准
个别在一个文件中,先导入内置模块,再导入第三方包模块,最初导入工程内本人写的模块。
举例:
#导入内置模块 import os import datetime #导入第三方包 import keras import pandas as pd #导入本人的模块 import package_1
总结
在 Python3.x 中,相对导入是默认的导入模式,也是 PEP 8 举荐的导入模式,它相当直观,能够很明确的晓得要导入的包或模块在哪里。且包的名称变动须要在导入的时候对应的批改。之后工程外部的导入尽量都是用相对导入。
这里有一个问题,如果包的构造非常复杂,各类援用又要相对援用,会让包导入的过程十分臃肿且难记,
举例:在package_1的内部想从package_1中的module_1_1中导入Cls1_1对象
from package_1.package_1_1.module_1_1 import Cls1_1
这种时候能够通过组织各package中的__init__文件来使导入更为不便,在python中当调用某包时,首先会运行其上面的init文件,如果在init中将该包上面的一些对象导入进去,在内部调用时就不必一层层调用了。
举例:
在package_1下的init文件中增加:
from package_1.package_1_1.module_1_1 import Cls1_1
那么在内部某模块中,如果想调用module_1_1中导入Cls1_1对象,则只须要
from package_1 import Cls1_1