AST (抽象構文木) の変更管理ポリシーの策定

原文はこちら: Formalizing the AST Change Control Policy

Python は、 AST モジュール を使用して、ソースコードをコンパイルした形で表現される AST (抽象構文木) を見えるようにしています。AST モジュールを使用すると、ソースコードを構文解析してバイトコードにコンパイルされる途中の過程で、ユーザが AST で表現されたものを操作したり検査したりできます。

Python コードの構文や意味論は、 言語リファレンス で定義されていますが、AST モジュールは、CPython の実装における詳細であり、他の Python 実装で実装される必要があるわけではありません。

AST の互換性

(これまでのところ、raw バイトコードというより) AST で動作する CPython オプティマイザを書き直す 作業 の一環として、Eugene Toder は AST の構造を変更する必要がありました。CPython の実装のように、後方互換性のポリシーが AST に適用されるものかどうか、すぐに分からないので、Eugene は python-dev で 質問しました 。AST が変更されるときに後方互換性を保証する必要はありますか？

その互換性は 必要ない という合意になりました。AST モジュールには定数 ast.__version__ があります。これは使用する AST のバージョンに依存してその動作が変わることをユーザへ伝えるコードです。実装に特化したモジュールにとってはこの情報が十分な互換性と考えられました。

他の Python の実装

実際の事実として、Jython と IronPython 双方のメンテナは、彼らのプロジェクトのそれぞれの実装も AST モジュール、またはその機能を提供するモジュールと互換性があることを指摘しました。たとえそうでも、彼らはそのことから AST モジュールを凍結すべきだという考えではありませんでした。そして、AST が互換性のない方法で変更されても ast.__version__ という定数も変更されるのであれば十分だと考えています。

議論になったポイントの1つは、他の実装の AST 表現が CPython と互換性があることを保証するのに便利な test_ast.py のテスト一式です。 test_ast.py のカバレッジを上げることは、Python の内部構造に関わりたい人にとって良いプロジェクトになります！

この後どうなるの？

議論を起こした パッチ はまだ CPython に取り込まれていません。そのため、しばらくは何も起きません。しかし、そのパッチがコミットされると、AST は互換性のない方法で変更する 予定 です。 ast.__version__ 定数は、このことを反映して変更します。そのため、ユーザコードでも分かりますが、変更が必要になります。一般的にこの内容は将来的に AST の変更を扱う方法になるでしょう。

Python の開発者は、AST がどのぐらい広く使われているか、このポリシーの変更がどのぐらい影響するのかに関心があります。もし、この変更が影響を及ぼすコードをもったユーザがいたら、 python-dev の議論 に参加されることをお奨めします。