如何解决Python中的循环模块依赖关系和相对导入
| 假设我们有两个具有循环依赖性的模块:# a.py
import b
def f(): return b.y
x = 42
# b.py
import a
def g(): return a.x
y = 43
这两个模块位于目录pkg
中,而空白__init__.py
。如此答案中所述,导入pkg.a
或pkg.b
可以正常工作。如果我将进口改为相对进口
from . import b
尝试导入以下模块之一时,出现“ѭ7”字样:
>>> import pkg.a
Traceback (most recent call last):
File \"<stdin>\",line 1,in <module>
File \"pkg/a.py\",in <module>
from . import b
File \"pkg/b.py\",in <module>
from . import a
ImportError: cannot import name a
为什么会出现此错误?情况与上面的情况大不相同吗? (这与这个问题有关吗?)
编辑:这个问题与软件设计无关。我知道避免循环依赖的方法,但是无论如何我都对错误的原因感兴趣。
解决方法
首先让我们从
from import
在python中的工作开始:
好吧,让我们看一下字节码:
>>> def foo():
... from foo import bar
>>> dis.dis(foo)
2 0 LOAD_CONST 1 (-1)
3 LOAD_CONST 2 ((\'bar\',))
6 IMPORT_NAME 0 (foo)
9 IMPORT_FROM 1 (bar)
12 STORE_FAST 0 (bar)
15 POP_TOP
16 LOAD_CONST 0 (None)
19 RETURN_VALUE
有趣的是:),所以from foo import bar
首先翻译为IMPORT_NAME foo
,相当于import foo
,然后是then14ѭ。
现在ѭ15做什么?
让我们看看当他发现IMPORT_FROM
时python会做什么:
TARGET(IMPORT_FROM)
w = GETITEM(names,oparg);
v = TOP();
READ_TIMESTAMP(intr0);
x = import_from(v,w);
READ_TIMESTAMP(intr1);
PUSH(x);
if (x != NULL) DISPATCH();
break;
好吧,基本上他得到了要导入的名称,在我们的foo()
函数中将是bar
,然后他从帧堆栈中弹出了值v
,这是最后执行的操作码return21ѭ的返回,然后调用函数import_from()
有这两个参数:
static PyObject *
import_from(PyObject *v,PyObject *name)
{
PyObject *x;
x = PyObject_GetAttr(v,name);
if (x == NULL && PyErr_ExceptionMatches(PyExc_AttributeError)) {
PyErr_Format(PyExc_ImportError,\"cannot import name %S\",name);
}
return x;
}
如您所见,import_from()
函数非常简单,它首先尝试从模块v
获得属性name
,如果不存在,则将其抬高ImportError
,否则返回此属性。
现在,这与相对导入有什么关系?
例如,在OP问题中,ѭ28等相对导入等价于ѭ29。
但是,这是怎么发生的呢?为了理解这一点,我们应该看一下python的import.c
模块,特别是get_parent()函数。如您所见,该函数在此处列出很长,但通常来说,当它看到相对导入时,它的作用是根据__main__
模块,尝试用父包替换点.
,这再次来自OP问题是包装pkg
。
现在,我们将所有这些放在一起,并尝试找出为什么我们最终会遇到OP问题中的行为。
为此,如果我们可以看到python在执行导入时会做什么,这将对我们有帮助,很幸运,这是我们已经幸运地拥有此功能的python了,可以通过在额外的详细模式下运行它来启用它(-vv
)。
因此,使用命令行:python -vv -c \'import pkg.b\'
:
Python 2.6.5 (r265:79063,Apr 16 2010,13:57:41)
[GCC 4.4.3] on linux2
Type \"help\",\"copyright\",\"credits\" or \"license\" for more information.
import pkg # directory pkg
# trying pkg/__init__.so
# trying pkg/__init__module.so
# trying pkg/__init__.py
# pkg/__init__.pyc matches pkg/__init__.py
import pkg # precompiled from pkg/__init__.pyc
# trying pkg/b.so
# trying pkg/bmodule.so
# trying pkg/b.py
# pkg/b.pyc matches pkg/b.py
import pkg.b # precompiled from pkg/b.pyc
# trying pkg/a.so
# trying pkg/amodule.so
# trying pkg/a.py
# pkg/a.pyc matches pkg/a.py
import pkg.a # precompiled from pkg/a.pyc
# clear[2] __name__
# clear[2] __file__
# clear[2] __package__
# clear[2] __name__
# clear[2] __file__
# clear[2] __package__
...
Traceback (most recent call last):
File \"<string>\",line 1,in <module>
File \"pkg/b.py\",in <module>
from . import a
File \"pkg/a.py\",line 2,in <module>
from . import a
ImportError: cannot import name a
# clear __builtin__._
嗯,ѭ7之前发生了什么?
首先)调用pkg/b.py
中的from . import a
,如上所述,将其转换为from pkg import a
,再次以字节码表示等同于import pkg; getattr(pkg,\'a\')
。但是等一下a
也是模块吗?
好了,这是有趣的部分,如果我们有类似ѭ43的东西,在这种情况下,将发生第二次导入,即import子句中模块的导入。因此,在OP示例中,我们现在需要导入pkg/a.py
,正如您所知,首先在ѭ45set中设置新模块的密钥,即pkg.a
,然后继续解释模块pkg/a.py
,但在该模块之前pkg/a.py
完成导入后称为from . import b
。
现在进入第二部分,pkg/b.py
将被导入,然后它将首先尝试to51ѭ,因为because2ѭ已经被导入,因此our45ѭ中有一个键pkg
,它将只返回该键的值。然后,import b
将in45中的pkg.b
键设定并开始解释。然后我们到达这条线from . import a
!
但是请记住,已经导入了“ 44”,这意味着“ 60”,因此导入将被跳过,只有“ 61”会被调用,但是会发生什么呢? python尚未完成导入pkg/a.py
!因此,仅会调用getattr(pkg,\'a\')
,这会在import_from()
函数中引发AttributeError
,并将其转换为ImportError(cannot import name a)
。
免责声明:这是我自己的工作,以了解口译员内部发生的事情,我远不是专家。
EDIt:改写了这个答案,因为当我再次尝试阅读它时,我指出了我的答案是不好的,希望现在它会更有用:)
,(通常,相对导入无关紧要。使用from pkg import
...会显示相同的异常。)
我认为这是from foo import bar
和import foo.bar
之间的区别在于,在第一个中,one19ѭ的值可以是pkgfoo
中的模块,也可以是模块foo
中的变量。在第二种情况下,对于“ 19”来说,除模块/软件包以外的任何内容都是无效的。
这很重要,因为如果知道bar是一个模块,则sys.modules
的内容足以填充它。如果它可能是ѭ71模块中的变量,那么解释器实际上必须查看foo
的内容,但是在导入foo
时,那将是无效的。实际模块尚未填充。
在相对导入的情况下,我们理解“ѭ78”是指从包含当前模块的包中导入bar模块,但这实际上只是语法糖,“ѭ31”的名称被翻译为完全限定名称并传递给“ѭ80”,并且因此,它就像模棱两可的for11ѭ
, 另外请注意:
我有以下模块结构:
base
+guiStuff
-gui
+databaseStuff
-db
-basescript
我希望能够以import base.basescript
运行我的脚本,但是由于gui
文件具有import base.databaseStuff.db
导致导入base
,所以此操作失败并出现错误。由于ѭ86only仅注册为ѭ32caused,因此会导致第二次执行整个导入操作,并且会产生上述错误,除非我在base
之上使用外部脚本,从而仅导入base
/basescript
一次。为了防止这种情况,我在基本脚本中添加了以下内容:
if __name__ == \'__main__\' or \\
not \'__main__\' in sys.modules or \\
sys.modules[\'__main__\'].__file__ != __file__:
#imports here
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。