来自<模块>; import ... in __init__.py 使模块名称可见?模块>
采取以下代码示例:
文件 package1/__init__.py
:
from moduleB import foo
print moduleB.__name__
文件 package1/moduleB.py
:
def foo(): pass
然后从当前目录:
>>> import package1
package1.moduleB
此代码在 CPython 中运行。令我惊讶的是,__init__.py
语句中的 from ... import
使 moduleB
名称可见。根据 Python 文档,情况不应该是这样:
from表单不绑定模块名称
有人可以解释一下为什么 CPython 会这样工作吗?有没有详细描述这一点的文档?
Take the following code example:
File package1/__init__.py
:
from moduleB import foo
print moduleB.__name__
File package1/moduleB.py
:
def foo(): pass
Then from the current directory:
>>> import package1
package1.moduleB
This code works in CPython. What surprises me about it is that the from ... import
in __init__.py
statement makes the moduleB
name visible. According to Python documentation, this should not be the case:
The from form does not bind the module name
Could someone please explain why CPython works that way? Is there any documentation describing this in detail?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
该文档误导了您,因为它是为了描述从包含该模块的父包外部导入模块的更常见情况而编写的。
例如,在我自己的代码中使用“from example import submodule”,其中“example”是一些与我自己的代码完全无关的第三方库,不会绑定名称“example”。它仍然导入 example/__init__.py 和 example/submodule.py 模块,创建两个模块对象,并将 example.submodule 分配给第二个模块对象。
但是,子模块中名称的“from..import”必须在父包对象上设置子模块属性。考虑一下是否没有:
package/__init__.py 在导入包时执行。
__init__ 执行“从子模块导入名称”。
在稍后的某个时刻,其他完全不同的代码执行“import package.submodule”。
在步骤 3 中,要么 sys.modules["package.submodule"] 不存在,在这种情况下再次加载它会为您提供两个不同作用域中的不同模块对象;或 sys.modules["package.submodule"] 将存在,但 "submodule" 不会是父包对象 (sys.modules["package"]) 的属性,并且 "import package.submodule" 将不执行任何操作。但是,如果它什么都不做,那么使用 import 的代码就无法将子模块作为包的属性来访问!
从理论上讲,如果导入机制的其余部分进行了更改以匹配,则可以更改导入子模块的工作方式。
如果您只需要知道从包 P 导入子模块 S 会做什么,那么简而言之:
setattr(sys.modules["P"], "S", sys.modules["PS"])
The documentation misled you as it is written to describe the more common case of importing a module from outside of the parent package containing it.
For example, using "from example import submodule" in my own code, where "example" is some third party library completely unconnected to my own code, does not bind the name "example". It does still import both the example/__init__.py and example/submodule.py modules, create two module objects, and assign example.submodule to the second module object.
But, "from..import" of names from a submodule must set the submodule attribute on the parent package object. Consider if it didn't:
package/__init__.py executes when package is imported.
That __init__ does "from submodule import name".
At some point later, other completely different code does "import package.submodule".
At step 3, either sys.modules["package.submodule"] doesn't exist, in which case loading it again will give you two different module objects in different scopes; or sys.modules["package.submodule"] will exist but "submodule" won't be an attribute of the parent package object (sys.modules["package"]), and "import package.submodule" will do nothing. However, if it does nothing, the code using the import cannot access submodule as an attribute of package!
Theoretically, how importing a submodule works could be changed if the rest of the import machinery was changed to match.
If you just need to know what importing a submodule S from package P will do, then in a nutshell:
setattr(sys.modules["P"], "S", sys.modules["P.S"])
这是因为
__init__.py
在运行时将自身表示为 package1 模块对象,因此每个 .py 文件都将被定义为子模块。并重写__all__
没有任何意义。您可以创建另一个文件,例如 example.py 并在__init__.py
中填充相同的代码,它将引发NameError
。我认为 CPython 运行时在 __init__.py 寻找与其他 python 文件不同的变量时采用特殊算法,可能是这样的:
this is because
__init__.py
represent itself as package1 module object at runtime, so every .py file will be defined as an submodule. and rewrite__all__
will not make any sense. you can make another file e.g example.py and fill it with the same code in__init__.py
and it will raiseNameError
.i think CPython runtime takes special algorithm when
__init__.py
looking for variables differ from other python files, may be like this: