Saturday, May 14, 2011

正式确定改变AST的控制原则

原文链接: Formalizing the AST Change Control Policy

Python 在 AST 模块 中提供给 大家能够表示Python 源代码编译后形式的抽象语法树(AST)。用户可以通过AST模块在解析 和编译字节码之间审察和控制AST的表示形式。

尽管在 language reference 中 定义了Python 代码, AST 模块只是CPython 实现的细节,而不是其他Python实现必须的。

AST 的兼容性

work 中一部分指明要重写CPython的peephole 优化器,使它能工作在AST上(而不是像当前这样工作在原始的字节码上),因此Eugene Toder 觉得需要对AST的结构做一下调整。 作为一个CPython 实现细节, AST的向后兼容 原则并不是非常的明确。因此, Eugene在 python-dev 中 提出了这个问题. 当改变AST时,是否需要确保向后兼容性?

大家的一直意见是兼容性是 必要的。AST模块中有一个常量, ast.__version__, 能够让用户代码根据AST的版本来改变行为。这对那些针对特定Python实现的模块能够提供 足够的兼容性。

其他的Python实现

实际上,Jython 和 IronPython 维护者都指出他们相应的实现中要么会有一个兼容版本 的AST模块,要么会自己打算提供一个。即使这样,他们也觉得不应该冻结AST,而且很支持 AST模块根据 ant.__version__ 常量的改变以不兼容的方式进行修改。

还有一点需要指出的是: test_ast.py 中的全套测试很够帮助其他Python实现 确保他们的AST 表示形式是和CPython相兼容的。对于那些想参与到Python内部实现的人来说, 提升 test_ast.py 的覆盖范围是个很好的项目。

接下来会发生什么?

那个引发讨论的 补丁 还没放入CPython。 因此,有可能,什么都不会发生。然而,如果这个补丁通过了,那么 AST 将会 以不兼容 的方式改变。 ast.__version__ 常量会相应的进行改变,因此用户的代码会知道 这个变化,而且改变确实是需要的。更一般的说法是,将来AST也会按照这种方式改变。

Python开发者们很想知道AST模块使用程度到底有多广,以及这个原则到底影响会有多大。 如果有读者朋友的代码会收到影响,欢迎参加 python-dev上的讨论.

No comments:

Post a Comment