Python 3.6项目结构导致RuntimeWarning

时间：2017-04-13 13:34:24

标签： python python-3.x

我正在尝试打包我的项目以进行分发，但是当我运行该模块时，我正在点击RuntimeWarning。

我在Python mailing list上发现了一个错误报告，指出RuntimeWarning是Python 3.5.2中引入的新行为。

阅读错误报告，似乎发生了双重导入，并且RuntimeWarning在警告用户时是正确的。但是，我没有看到我需要对自己的项目结构进行哪些更改以避免此问题。

这是我试图“正确”构建的第一个项目。我希望在推送代码时有一个整洁的布局，以及一个可以被其他人轻松克隆和运行的项目结构。

我的结构主要基于http://docs.python-guide.org/en/latest/writing/structure/。

我在下面添加了最低工作示例的详细信息。

要复制此问题，我使用python -m运行主文件：

(py36) X:\test_proj>python -m proj.proj
C:\Users\Matthew\Anaconda\envs\py36\lib\runpy.py:125: RuntimeWarning: 
'proj.proj' found in sys.modules after import of package 'proj', but prior 
to execution of 'proj.proj'; this may result in unpredictable behaviour
  warn(RuntimeWarning(msg))
This is a test project.`

运行我的测试很好：

(py36) X:\test_proj>python -m unittest tests.test_proj
This is a test project.
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

复制问题的项目结构如下：

myproject/
    proj/
        __init__.py
        proj.py
    tests/
        __init__.py
        context.py
        test_proj.py

在文件proj/proj.py中：

def main():
    print('This is a test project.')
    raise ValueError

if __name__ == '__main__':
    main()

在proj/__init__.py：

from .proj import main

在tests/context.py：

import os
import sys
sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))
import proj

最后，在tests/test_proj.py：

import unittest

from .context import proj


class SampleTestCase(unittest.TestCase):
    """Test case for this sample project"""
    def test_raise_error(self):
        """Test that we correctly raise an error."""
        with self.assertRaises(ValueError):
            proj.main()


if __name__ == '__main__':
    unittest.main()

任何人都可以帮我纠正我的项目结构以避免这种双重导入方案吗？对此的任何帮助将不胜感激。

5 个答案:

答案 0 :(得分：19)

对于这种特殊情况，双重导入警告是由于proj/__init__.py中的这一行：

from .proj import main

该行的含义是，当-m切换实施完成import proj步骤时，proj.proj已将已导入为副作用导入父包。

避免警告

为避免出现此警告，您需要找到一种方法来确保导入父包不会隐式导入使用-m开关执行的包。

解决的两个主要选项是：

  1. 删除from .proj import main行（如@John Moutafis建议的那样），假设可以在不破坏API兼容性保证的情况下完成;或

  2. 从if __name__ == "__main__":子模块中删除proj块，并将其替换为单独的proj/__main__.py文件：

    from .proj import main
main()

    3. 如果使用选项2，那么命令行调用也将更改为python -m proj，而不是引用子模块。

    选项2的更向后兼容的变体是添加__main__.py而不从当前子模块中删除CLI块，并且当与DeprecationWarning结合使用时，这可能是一种特别好的方法：

    if __name__ == "__main__":
    import warnings
    warnings.warn("use 'python -m proj', not 'python -m proj.proj'", DeprecationWarning)
    main()

    如果proj/__main__.py已用于某些其他目的，那么您也可以执行将python -m proj.proj替换为python -m proj.proj_cli，其中proj/proj_cli.py如下所示：

    if __name__ != "__main__":
    raise RuntimeError("Only for use with the -m switch, not as a Python API")
from .proj import main
main()

    为什么警告存在？

    当-m开关实现即将开始并在__main__模块中再次运行已导入模块的代码 时，会发出此警告，这意味着您将有两个它定义的所有内容的不同副本 - 类，函数，容器等。

    根据应用程序的具体情况，这可能正常工作（这就是为什么它是警告而不是错误），或者它可能导致奇怪的行为，如模块级状态修改未按预期共享，甚至不是异常被捕获是因为异常处理程序试图从模块的一个实例捕获异常类型，而引发的异常使用了另一个实例中的类型。

    因此模糊的this may cause unpredictable behaviour警告 - 如果由于运行模块的顶级代码两次而出现问题，则症状几乎可以是任何事情。

    如何调试更复杂的案例？

    虽然在这个特定的例子中，副作用导入直接在proj/__init__.py中，但是有一个更加微妙且难以调试的变体，而父包则改为：

    import some_other_module

    然后它是some_other_module（或它导入的模块）：

    import proj.proj # or "from proj import proj"

    假设错误行为是可重现的，调试这些问题的主要方法是以详细模式运行python并检查导入序列：

    $ python -v -c "print('Hello')" 2>&1 | grep '^import'
import zipimport # builtin
import site # precompiled from /usr/lib64/python2.7/site.pyc
import os # precompiled from /usr/lib64/python2.7/os.pyc
import errno # builtin
import posix # builtin
import posixpath # precompiled from /usr/lib64/python2.7/posixpath.pyc
import stat # precompiled from /usr/lib64/python2.7/stat.pyc
import genericpath # precompiled from /usr/lib64/python2.7/genericpath.pyc
import warnings # precompiled from /usr/lib64/python2.7/warnings.pyc
import linecache # precompiled from /usr/lib64/python2.7/linecache.pyc
import types # precompiled from /usr/lib64/python2.7/types.pyc
import UserDict # precompiled from /usr/lib64/python2.7/UserDict.pyc
import _abcoll # precompiled from /usr/lib64/python2.7/_abcoll.pyc
import abc # precompiled from /usr/lib64/python2.7/abc.pyc
import _weakrefset # precompiled from /usr/lib64/python2.7/_weakrefset.pyc
import _weakref # builtin
import copy_reg # precompiled from /usr/lib64/python2.7/copy_reg.pyc
import traceback # precompiled from /usr/lib64/python2.7/traceback.pyc
import sysconfig # precompiled from /usr/lib64/python2.7/sysconfig.pyc
import re # precompiled from /usr/lib64/python2.7/re.pyc
import sre_compile # precompiled from /usr/lib64/python2.7/sre_compile.pyc
import _sre # builtin
import sre_parse # precompiled from /usr/lib64/python2.7/sre_parse.pyc
import sre_constants # precompiled from /usr/lib64/python2.7/sre_constants.pyc
import _locale # dynamically loaded from /usr/lib64/python2.7/lib-dynload/_localemodule.so
import _sysconfigdata # precompiled from /usr/lib64/python2.7/_sysconfigdata.pyc
import abrt_exception_handler # precompiled from /usr/lib64/python2.7/site-packages/abrt_exception_handler.pyc
import encodings # directory /usr/lib64/python2.7/encodings
import encodings # precompiled from /usr/lib64/python2.7/encodings/__init__.pyc
import codecs # precompiled from /usr/lib64/python2.7/codecs.pyc
import _codecs # builtin
import encodings.aliases # precompiled from /usr/lib64/python2.7/encodings/aliases.pyc
import encodings.utf_8 # precompiled from /usr/lib64/python2.7/encodings/utf_8.pyc

    这个特殊的例子只显示Fedora上的Python 2.7在启动时所做的基本导入集。调试这个问题中的双重导入RuntimeWarning时，你会在详细输出中搜索“import proj”然后“import proj.proj”行，然后仔细查看导入紧接在“import proj.proj”行之前。

答案 1 :(得分：9)

如果您查看double import trap，您会看到：

  

这个下一个陷阱存在于所有当前版本的Python中，包括   3.3，可以归纳为以下一般准则：“永远不要添加包目录，或包内的任何目录，直接   到Python路径“。

     

这是有问题的原因是该目录中的每个模块   现在可以通过两个不同的名称访问：作为顶部   level模块（因为目录在sys.path上）和子模块   包（如果包含包的更高级目录）   本身也在sys.path上。

在tests/context.py

删除：sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

这可能会导致问题，您的代码仍然按预期工作。

<小时/> 因评论而修改：

您可以尝试更改代码中的某些部分：

  1. proj/__init__.py可以完全为空

  2. 在test_proj.py上应更改导入，如下所示：

    import unittest

from proj import proj

    3. PS：我无法使用您的初始代码或我的建议在Linux上重现警告。

答案 2 :(得分：3)

@ncoghlan的答案是正确的。我只想添加到他的解决方案1中，如果您使用__init__.py开关执行软件包，则只​​需删除-m中的导入。可以归结为在__init__.py中确定是否使用-m开关调用了python。 sys.flags不幸的是没有包含-m开关的条目，但是sys.argv似乎只包含一个包含“ -m”的元素（但是我没有弄清楚这种行为是否是加倍）。因此，可以通过以下方式更改__init__.py：

import sys
if not '-m' in sys.argv:
    from .proj import main

如果使用-m开关执行软件包，.proj将不会导入__init__.py，并且避免了双重导入。如果从另一个脚本导入软件包，则.proj将按预期导入。不幸的是，sys.argv不包含-m开关的参数！因此，将main（）函数移动到单独的文件也许是更好的解决方案。但是我真的很想在我的模块中有一个main（）函数，以进行快速，简单的测试/演示。

答案 3 :(得分：1)

python -m有点棘手。 @ncoghlan已经提供了详细信息。 当我们尝试使用python -m运行时，默认情况下会导入sys.path / pythonpath中的所有包。如果您的包具有对PATH目录中任何内容的import语句，则会出现上述警告。See the Pic

我的PYTHONPATH已经有了Project目录。因此，当我做

from reader.reader import Reader

系统抛出警告。因此，如果路径在python路径中，则无需显式导入

答案 4 :(得分：1)

如果您确定警告与您无关，那么避免它的一种简单方法是通过实现runpy开关背后逻辑的-m模块忽略RuntimeWarning：

import sys
import warnings

if not sys.warnoptions:  # allow overriding with `-W` option
    warnings.filterwarnings('ignore', category=RuntimeWarning, module='runpy')

这显然也可能隐藏相关警告，但至少目前这是runpy使用的唯一RuntimeWarning。或者，可以通过为必须发出警告的消息或行号指定模式来更严格地进行过滤，但如果稍后编辑runpy，则可能会破坏这两种模式。

相关问题
最新问题