摘要

本 PEP 提案从 Python 中移除 PYO 文件的概念。为了继续支持根据优化级别分离字节码文件，本 PEP 提案建议在应用优化时，扩展 PYC 文件名以在字节码库目录中包含优化级别。

理由

截至目前，字节码文件有两种形式：PYC 和 PYO。PYC 文件是在解释器启动时未指定优化级别（即未指定 -O）时生成和读取的字节码文件。PYO 文件表示在指定 **任何** 优化级别（即指定 -O **或** -OO）时读取/写入的字节码文件。这意味着，虽然 PYC 文件清楚地界定了生成它们时使用的优化级别（即除了 peepholer 之外没有优化），但 PYO 文件并非如此。用优化级别和文件扩展名来表达：

• 0: .pyc
• 1 (-O): .pyo
• 2 (-OO): .pyo

将 .pyo 文件扩展名用于 1 级和 2 级优化意味着无法清楚地判断生成字节码文件时使用了什么优化级别。在读取 PYO 文件时，如果用户没有仔细确保所有 PYO 文件都是使用相同的优化级别生成的（通常通过盲目删除所有 PYO 文件，然后使用 compileall 模块编译所有新的 PYO 文件 [1] 完成），这会导致解释器使用混合的优化级别运行其代码。当人们对 Python 代码进行超出解释器原生支持的优化时，例如使用 astoptimizer 项目 [2]，这个问题会更加严重。

在写入 PYO 文件时，每次更改要使用的优化级别或不确定上次生成 PYO 文件时使用了什么优化级别时，都需要删除所有 PYO 文件，这会导致不必要的文件 churn。本 PEP 提案的更改还允许为字节码文件预先编译 **所有** 优化级别，这在当前情况下是不可能的，因为 .pyo 文件扩展名被用于多个优化级别。

至于分发仅包含字节码的模块，对于代码混淆和较小的文件部署的常见用例，分发 .pyc 和 .pyo 文件都是不必要的。这意味着仅包含字节码的模块将只从其非优化的 .pyc 文件名加载。

提案

为了消除 PYO 文件带来的歧义，本 PEP 提案建议消除 PYO 文件及其伴随的 .pyo 文件扩展名。为了使优化级别变得明确，并避免在 __pycache__ 目录中不必要地重新生成优化的字节码文件，用于生成字节码文件的优化级别将被纳入字节码文件名。当未指定优化级别时，将使用 PEP 之前的 .pyc 文件名（即文件名中不会指定优化级别）。例如，在 CPython 3.5 中，名为 foo.py 的源文件可能具有以下字节码文件，具体取决于解释器的优化级别（无、-O 和 -OO）：

• 0: foo.cpython-35.pyc （即没有变化）
• 1: foo.cpython-35.opt-1.pyc
• 2: foo.cpython-35.opt-2.pyc

目前，字节码文件名由 importlib.util.cache_from_source() 创建，大致使用 PEP 3147 [3]、[4] 定义的以下表达式：

'{name}.{cache_tag}.pyc'.format(name=module_name,
                                cache_tag=sys.implementation.cache_tag)

本 PEP 提案建议在指定优化级别时更改表达式：

'{name}.{cache_tag}.opt-{optimization}.pyc'.format(
        name=module_name,
        cache_tag=sys.implementation.cache_tag,
        optimization=str(sys.flags.optimize))

选择 “opt-” 前缀是为了提供一个与缓存标记的视觉分隔符。选择将优化级别放在缓存标记之后是为了保留基于模块名和缓存标记的字节码文件名的词典顺序，这对于单个解释器来说是不会变化的。“opt-” 前缀被选择而不是 “o”，这样可以自我说明。“opt-” 前缀被选择而不是 “O”，是为了避免在优化级别以 “0” 开头时造成混淆。

选择句号而不是连字符作为分隔符，是为了明确区分优化级别不是缓存标记中指定的解释器版本的一部分。它也借鉴了使用句号在文件名中划分语义上不同的概念。

例如，如果向解释器传递了 -OO，那么文件名将是 importlib.cpython-35.opt-2.pyc，而不是 importlib.cpython-35.pyo。

在未应用优化级别时省略新的 opt- 标记应提高向后兼容性。这对于没有使用优化级别的 Python 实现（例如 PyPy [10]）来说也更理解。

需要注意的是，这种更改不会影响导入的性能。由于导入系统已经根据解释器的优化级别查找单个字节码文件，如果文件不存在则生成一个新的字节码文件，因此在 __pycache__ 目录中引入更多可能的字节码文件不会对 stat 调用产生任何影响。解释器将继续根据优化级别只查找一个字节码文件，因此不会增加 stat 调用次数。

本 PEP 提案的唯一潜在负面结果是可能增加 .pyc 文件的数量，从而增加存储使用量。但对于存储空间有限的平台，可以使用 sys.dont_write_bytecode 关闭字节码生成，以便能够离线控制。

实现

本 PEP 提案的实现可在此处获得 [11]。

importlib.util.cache_from_source(path, debug_override=None)

importlib.util.cache_from_source(path, debug_override=None, *, optimization=None)

兼容性注意事项

从 Python 3.2 开始，任何直接操作字节码文件的代码都需要考虑此更改对其代码的影响（在 Python 3.2 之前——包括所有 Python 2——不存在 __pycache__，这已经需要对字节码文件处理支持进行二分）。如果代码将 debug_override 参数设置为 importlib.util.cache_from_source()，那么如果他们想要优化级别为 2 的字节码文件的路径，则需要谨慎。否则，只有 **不** 使用 importlib.util.cache_from_source() 的代码才需要更新。

至于那些分发仅包含字节码的模块的人（即，使用字节码文件而不是源文件），他们将不得不选择他们希望字节码文件的优化级别，因为分发一个 .pyo 文件和一个 .pyc 文件将不再有任何用处。由于人们通常只为代码混淆目的或更小的分发大小分发字节码文件，因此只需要分发一个 .pyc 实际上对这些用例是有益的。由于字节码文件的魔数在 Python 3.5 中发生了改变，以支持 PEP 465，因此无需支持现有的 .pyo 文件 [8]。

被拒绝的想法

参考

版权

此文档已置于公有领域。