*If* the PEP 511 is accepted, it will be super easy to start with an
implementation in pure Python.

But I think that we should benchmark the overhead of the Python API of
PEP 511, because we need to convert all AST internal objects to Python
objects, run the AST optimizer, and then again convert Python objects
to internal AST objects.

For a long running process, the time to compile a .py file doesn't
matter. For a short script, it matters. At least, we need to compile
the script itself.

By the way, would it be insane to *not* optimize the script when
running "python script.py"?

> Now with the Constant node this should be easy.

ast.Constant is *not* emited by the compiler to not break backward
compatibility. I *know* that there is no stable API on AST, but I
noticed some issues when working on my AST project. For example, pip
doesn't work because an internal library uses AST and the code doesn't
handle ast.Constant (it's probably super easy to fix it).

I'm open to change the compiler to emit ast.Constant directly, but
maybe only in "optimized mode" (ex: python -O?). ast.Constant for
tuples and frozensets has a limitation: it doesn't store the location
of items (line number, column offset).