gpt4 book ai didi

python - issubclass() 行为根据导入而改变

转载 作者:太空宇宙 更新时间:2023-11-04 04:56:10 24 4
gpt4 key购买 nike

我试图找出为什么 issubclass() 的行为会根据类的导入方式发生变化。

我有以下设置

proj
|_pkg
|_ __init__.py
|_ base.py
|_ child.py

base.py 有

class Base(object):
pass

child.py 有

from base import Base

class Child(Base):
pass

然后我在 shell 中执行以下操作:

$export PYTHONPATH='/tmp/proj'
$ipython
In [1]: from pkg.base import Base as Base1

In [2]: from base import Base as Base2

In [3]: from pkg.child import Child as Child1

In [4]: from child import Child as Child2

In [5]: issubclass(Child1, Base1)
Out[5]: True # Makes Sense

In [6]: issubclass(Child1, Base2)
Out[6]: False # Confused. Why would this be False.

In [7]: issubclass(Child2, Base1)
Out[7]: False # Confused. Why would this be False.

In [8]: issubclass(Child2, Base2)
Out[8]: True

我对 [6] 和 [7] 中发生的事情感到困惑。我希望这些也是 True

最佳答案

经过一番挖掘后,在这里找到了答案 - http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#the-double-import-trap

This next trap exists in all current versions of Python, including 3.3, and can be summed up in the following general guideline: “Never add a package directory, or any directory inside a package, directly to the Python path”.

The reason this is problematic is that every module in that directory is now potentially accessible under two different names: as a top level module (since the directory is on sys.path) and as a submodule of the package (if the higher level directory containing the package itself is also on sys.path).

As an example, Django (up to and including version 1.3) used to be guilty of setting up exactly this situation for site-specific applications - the application ends up being accessible as both app and site.app in the module namespace, and these are actually two different copies of the module.

关于python - issubclass() 行为根据导入而改变,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/47005432/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com