为什么要导入 Python select 这个意外的模块
Why does Python select this unexpected module to import
我正在处理一个项目,该项目有一个名为 types.py
的用户编写的模块,埋在二级包中(它从项目根目录开始的路径是 package/subpackage/types.py
)。
这会导致问题,因为 Python 库也有一个 types
模块。当另一个 Python 库模块 enum.py
尝试导入 types
时,导入的是用户编写的版本,造成严重破坏。
令我困惑的是 enum.py
中的导入不符合 types
任何包名称:
# line 10 of enum.py:
from types import MappingProxyType, DynamicClassAttribute
那为什么Python选择用户写的types
,在二级分包里?在我看来,用户编写的 types
只有在使用
时才会被导入
# what I expect an 'import' would have to be like to access the user-written types.py
from package.subpackage.types import ...
另一种可能的解释是 sys.path
包含 package/subpackage
目录,但当我在 enum.py import
:
之前打印其内容时,情况并非如此
enum.py: Path:
/home/me/PycharmProjects/myproject
/home/me/anaconda3/envs/myproject/lib/python37.zip
/home/me/anaconda3/envs/myproject/lib/python3.7
/home/me/anaconda3/envs/myproject/lib/python3.7/lib-dynload
/home/me/anaconda3/envs/myproject/lib/python3.7/site-packages
那么,如何解释用户编写的types.py
模块的导入?
UPDATE:第一条评论表明发生这种情况是因为我的项目路径是 sys.path
中的第一项。但是,我建立了一个非常简单的项目,其中一个名为 mymodule
的模块位于 package.subpackage
:
在不使用包和子包名称的情况下从 mymodule
导入不起作用:
# main.py
# Works:
from package.subpackage.mymodule import my_module_field
# Does not work:
# from mymodule import my_module_field
所以我还是不明白为什么enum.py
中的from types import
可以找到没有包名的用户写的types.py
UPDATE 2:打印出更多信息,我看到当 enum.py
启动时我打印 sys.path
(我修改了标准库文件打印它),我看到 package/subpackage
目录 是 sys.path
中的 ,即使它不在执行开始时。所以这解释了为什么使用用户编写的typos.py
。
现在的问题是为什么 sys.path
附加在 package/subpackage
目录中。我在我的代码中搜索了所有 sys.path
的出现,即使当前目录在某些时候附加到它,它也永远不是 package/subpackage
目录。这会发生在哪里?
不确定这算不算真正的答案,因为根据问题信息本身不可能回答它(并且将所有细节添加到问题中是不切实际的)。无论如何,这就是解决方案。
基本上,经过进一步检查,我发现一个脚本调用另一个脚本作为外部进程,而后一个脚本位于 package/subpackage
目录中,该目录被添加到新目录中的 sys.path
过程。关于最后一点,我不确定为什么;我假设脚本的当前目录总是添加到 sys.path
.
我正在处理一个项目,该项目有一个名为 types.py
的用户编写的模块,埋在二级包中(它从项目根目录开始的路径是 package/subpackage/types.py
)。
这会导致问题,因为 Python 库也有一个 types
模块。当另一个 Python 库模块 enum.py
尝试导入 types
时,导入的是用户编写的版本,造成严重破坏。
令我困惑的是 enum.py
中的导入不符合 types
任何包名称:
# line 10 of enum.py:
from types import MappingProxyType, DynamicClassAttribute
那为什么Python选择用户写的types
,在二级分包里?在我看来,用户编写的 types
只有在使用
# what I expect an 'import' would have to be like to access the user-written types.py
from package.subpackage.types import ...
另一种可能的解释是 sys.path
包含 package/subpackage
目录,但当我在 enum.py import
:
enum.py: Path:
/home/me/PycharmProjects/myproject
/home/me/anaconda3/envs/myproject/lib/python37.zip
/home/me/anaconda3/envs/myproject/lib/python3.7
/home/me/anaconda3/envs/myproject/lib/python3.7/lib-dynload
/home/me/anaconda3/envs/myproject/lib/python3.7/site-packages
那么,如何解释用户编写的types.py
模块的导入?
UPDATE:第一条评论表明发生这种情况是因为我的项目路径是 sys.path
中的第一项。但是,我建立了一个非常简单的项目,其中一个名为 mymodule
的模块位于 package.subpackage
:
在不使用包和子包名称的情况下从 mymodule
导入不起作用:
# main.py
# Works:
from package.subpackage.mymodule import my_module_field
# Does not work:
# from mymodule import my_module_field
所以我还是不明白为什么enum.py
中的from types import
可以找到没有包名的用户写的types.py
UPDATE 2:打印出更多信息,我看到当 enum.py
启动时我打印 sys.path
(我修改了标准库文件打印它),我看到 package/subpackage
目录 是 sys.path
中的 ,即使它不在执行开始时。所以这解释了为什么使用用户编写的typos.py
。
现在的问题是为什么 sys.path
附加在 package/subpackage
目录中。我在我的代码中搜索了所有 sys.path
的出现,即使当前目录在某些时候附加到它,它也永远不是 package/subpackage
目录。这会发生在哪里?
不确定这算不算真正的答案,因为根据问题信息本身不可能回答它(并且将所有细节添加到问题中是不切实际的)。无论如何,这就是解决方案。
基本上,经过进一步检查,我发现一个脚本调用另一个脚本作为外部进程,而后一个脚本位于 package/subpackage
目录中,该目录被添加到新目录中的 sys.path
过程。关于最后一点,我不确定为什么;我假设脚本的当前目录总是添加到 sys.path
.