酷客网优先使用absolute import来导入模块，假设有如下文件结构，其中app/sub1/string.py中定义了一个lower()方法，那么当在mod1.py中import string之后再使用string.lower()方法时，到底引用的是sub1/string.py中的lower()方法，还是Python标准库中string里面的lower()方法呢？
app/
__init__.py
sub1/
__init__.py
mod1.py
string.py
sub2/
__init__.py
mod2.py
从程序的输出会发现，它引用的是app/sub1/string.py中的lower()方法。显然解释器默认先从当前目录下搜索对应的模块，当搜到string.py的时候便停止搜索进行动态加载。那么，如果要使用Python自带的string模块中的方法，该怎么实现呢？这就涉及absolute import和relative import相关的话题了。
在Python2.4以前默认为隐式的relative import，局部范围的模块将覆盖同名的全局范围的模块。如果要使用标注库中同名的模块，你不得不去深入考察sys.modules一番，显然这并不是一种非常友好的做法。Python2.5中后虽然默认的仍然是relative import，但它为absolute import提供了一种新的机制，在模块中使用from __future__ import absolute_import语句进行说明后再进行导入。同时它还通过点号提供了一种显式进行relative import的方法，“.”表示当前目录，“..”表示当前目录的上一层目录。例如想在mod1.py中导入string.py，可以使用from . import string，其中mod1所在的包层次结构为app.sub1.mod1，“.”表示app.sub1；如果想导入sub2/mo2.py可以使用from ..sub2 import mod2，“..”代表的是app。
但事情是不是就此结束了呢？远不止，使用显式relative import之后再运行程序一不小心你就有可能遇到这种错误“ValueError: Attempted relative import in non-package”。这是什么原因呢？这个问题产生的原因在于relative import使用模块的name属性来决定当前模块在包层次结构中的位置，如果当前的模块名称中不包含任何包的信息，那么它将默认为模块在包的顶层位置，而不管模块在文件系统中的实际位置。而在relative import的情形下，name会随着文件加载方式的不同而发生改变，上例中如在目录app/sub1/下运行Python mod1.py，会发现模块的name为main，但如果在目录app/sub1/下运行Python-m mod1.py，会发现name变为mod1。其中-m的作用是使得一个模块像脚本一样运行。而无论以何种方式加载，当在包的内部运行脚本的时候，包相关的结构信息都会丢失，默认当前脚本所在的位置为模块在包中的顶层位置，因此便会抛出异常。如果确实需要将模块当作脚本一样运行，解决方法之一是在包的顶层目录中加入参数-m运行该脚本，上例中如果要运行脚本mod1.py可以在app所在的目录的位置输入Python -m app.sub1.mod1。另一个解决这个问题的方法是利用Python2.6在模块中引入的package属性，设置package之后，解释器会根据package和name的值来确定包的层次结构。上面的例子中如果将mod1.py修改为以下形式便不会出现在包结构内运行模块对应的脚本时出错的情况了。
if __name__ == "__main__" and __package__ is None:
import sys
import os.path
sys.path[0] = os.path.abspath("./../../")
print sys.path[0]
import app.sub1
__package__ = str('app.sub1')
from . import string
相比于absolute import，relative import在实际应用中反馈的问题较多，因此推荐优先使用absolute import。absolute import可读性和出现问题后的可跟踪性都更好。当项目的包层次结构较为复杂的时候，显式relative import也是可以接受的，由于命名冲突的原因以及语义模糊等原因，不推荐使用隐式的relative import，并且它在Python3中已经被移除。
酷客网相关文章：
评论前必须登录！
注册