摘要

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

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

本 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 的轻微修改后，它们现在已经被签入。

参考资料

版权

本文档已置于公共领域。