摘要

如 PEP 236 中所述，“模拟交互式 Shell” 没有明确的方法来模拟“真实”交互式 Shell 中 __future__ 语句的行为，即让 __future__ 语句的效果持续 Shell 的整个生命周期。

PEP 还借此机会清理了 PEP 236 中提到的另一个未解决的问题，即 compile() 无法停止继承影响调用 compile() 的代码的未来语句效果。

本 PEP 建议通过向内置函数“compile”添加一个可选的第四个参数，向 __future__.py 中定义的 _Feature 实例添加信息，以及向标准库模块“codeop”和“code”添加机制来解决第一个问题，从而简化此类 Shell 的构建。

第二个问题可以通过简单地向 compile() 添加**另一个**可选参数来解决，如果该参数为非零值，则会抑制继承未来语句的效果。

规范

我建议向内置“compile”函数添加第四个可选的“flags”参数。如果省略此参数，则行为与 Python 2.1 相同。

如果存在，则它应该是一个整数，表示各种可能的编译时选项作为位字段。位字段将具有与 Python 解释器 C 部分已用于引用未来语句的 CO_* 标志相同的值。

compile() 如果不识别提供的标志中设置的任何位，则应引发 ValueError 异常。

提供的标志将与无论如何都会设置的标志进行按位“或”运算，除非新的第五个可选参数为非零整数，在这种情况下，提供的标志将完全是使用的集合。

上述标志目前尚未公开给 Python。我建议向 __future__.py 中的 _Feature 对象添加 .compiler_flag 属性，其中包含必要的位，因此您可以编写如下代码

import __future__
def compile_generator(func_def):
    return compile(func_def, "<input>", "suite",
                __future__.generators.compiler_flag)

最近的更改意味着可以使用相同的位来判断代码对象是否使用给定功能进行编译；例如

codeob.co_flags & __future__.generators.compiler_flag``

当且仅当代码对象“codeob”在允许生成器的环境中编译时，才会为非零值。

我还将向 __future__ 模块添加一个 .all_feature_flags 属性，提供一种低成本的方法来枚举运行时解释器支持的所有 __future__ 选项。

我还建议向标准库模块 codeop 添加一对类。

一个 - Compile - 将具有一个 __call__ 方法，该方法的行为与 2.1 中的内置“compile”非常相似，不同之处在于，在编译 __future__ 语句后，它会“记住”它并使用有效的 __future__ 选项编译所有后续代码。

它将通过使用上面提到的 __future__ 模块的新功能来实现。

添加到 codeop 的另一个类的对象 - CommandCompiler - 将执行现有 codeop.compile_command 函数的工作，但以 __future__ 识别的方式。

最后，我建议修改标准库模块 code 中的类 InteractiveInterpreter 以使用 CommandCompiler 更紧密地模拟默认 Python Shell 的行为。

向后兼容性

应该很少或没有；对 compile 的更改不会对现有代码产生任何影响，向 codeop 添加新函数或类也不会产生影响。使用 code.InteractiveInterpreter 的现有代码的行为可能会发生变化，但只会变得更好，因为“真实”的 Python Shell 将得到更好的模拟。

向前兼容性

在添加 __future__ 功能时，需要对 Lib/__future__.py 进行的调整会稍微复杂一些。其他所有内容都应该可以正常工作。

问题

我希望上述接口不会对 Jython 的实现造成太大干扰。

实现

一系列初步实现位于 [1]。

在 Tim Peters 稍作修改后，它们现已签入。

参考文献

版权

本文档已进入公有领域。