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 参考实现的 issue tracker 条目，当前的 PR 草案可在 GitHub 上找到。

开放问题

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

背景

我在调试一个主程序时 偶然发现了这个问题，该主程序通过一个模块尝试对一个已命名的模块进行猴子补丁，该模块就是主程序模块。自然地，猴子补丁无效，因为它按名称导入了主模块，从而修补了第二个模块实例，而不是正在运行的模块实例。

然而，这个问题自 -m 命令行选项存在以来一直存在，并且经常（尽管不频繁）被其他人遇到。

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

版权

本文档已置于公共领域。