PEP 延期

目前预计该 PEP 的实现不会在 2020 年 4 月的 Python 3.9 功能冻结之前准备好，因此已将其推迟 12 个月到 Python 3.10。

摘要

当模块在 Python 命令行上用作主程序时，例如通过

python -m module.name …

如果该模块在程序中再次导入，则很容易意外地得到该模块的两个独立实例。本 PEP 提出了一种解决此问题的方法。

当模块通过 Python 的 -m 选项调用时，该模块会绑定到 sys.modules['__main__']，并且其 .__name__ 属性设置为 '__main__'。这使得许多模块底部的标准“主程序”样板代码成为可能，例如

if __name__ == '__main__':
    sys.exit(main(sys.argv))

但是，当使用上述命令行调用时，自然会推断该模块实际上是在其官方名称 module.name 下导入的，因此如果程序再次导入该名称，则会获得相同的模块实例。

实际上，该模块仅作为 '__main__' 导入。另一个导入将获得一个不同的模块实例，这可能导致令人困惑的错误，所有这些错误都源于模块全局对象的两个实例：每个模块中一个。

示例包括

模块级数据结构

某些模块提供诸如缓存或注册表之类的功能作为模块级全局变量，通常是私有的。模块的第二个实例创建第二个数据结构。如果该结构是缓存（例如在 re 模块中），则存在两个缓存，导致内存浪费。如果该结构是共享注册表（例如值到处理程序的映射），则可以将处理程序注册到一个注册表，并尝试通过另一个注册表使用它，在该注册表中，它未知。

哨兵

由模块提供的哨兵值的标准测试是使用 is 进行身份比较，因为这避免了不可靠的“看起来像”比较（例如相等性），这些比较既可以将两个值错误地匹配为“相等”（例如为零值）或在对象不兼容时引发 TypeError。当模块有两个实例时，存在两个哨兵实例，并且只有一个可以通过 is 识别。

类

使用两个模块时，会存在任何提供的类的重复类定义。所有依赖于识别这些类及其子类的操作都可能发生故障，具体取决于从哪个模块获取参考类（来自其中一个模块）以及从何处获取比较类或实例。这会影响 isinstance、issubclass 以及 try/except 结构。

提案

建议要解决这种情况，只需简单地更改 -m 选项的实现方式即可：除了将模块对象绑定到 sys.modules['__main__'] 之外，还将其绑定到 sys.modules['module.name']。

Alyssa (Nick) Coghlan 建议这就像修改 runpy 模块的 _run_module_as_main 函数一样简单

main_globals = sys.modules["__main__"].__dict__

改为

main_module = sys.modules["__main__"]
sys.modules[mod_spec.name] = main_module
main_globals = main_module.__dict__

Joseph Jevnik 指出，作为包的模块已经执行了与此提案非常类似的操作：__init__.py 文件绑定到模块的规范名称，__main__.py 文件绑定到“__main__”。因此，不会出现双重导入问题。因此，本 PEP 提出仅影响简单的非包模块。

考虑因素和先决条件

参考实现

BPO 36375 是 PEP 参考实现的问题跟踪器条目，当前的草稿 PR 可在 GitHub 上找到。

未解决的问题

此提案确实引发了一些向后兼容性问题，这些问题需要充分理解，并设计一个弃用过程，或提供清晰的移植指南。

背景

我在调试主程序时偶然发现了此问题，该程序通过一个尝试修补命名模块（即主程序模块）的模块进行调试。当然，修补无效，因为它按名称导入了主模块，因此修补了第二个模块实例，而不是正在运行的模块实例。

但是，该问题一直存在于 -m 命令行选项存在以来，并且其他人经常（尽管不频繁）遇到该问题。

除了 问题 19702 之外，围绕 __main__ 的差异在 PEP 451 中有所提及，并且一个类似的提案（早于 PEP 451）在 PEP 395 中的 修复主模块的双重导入 部分进行了描述。

版权

本文档已置于公有领域。