[Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
Thomas Lee
tom at vector-seven.com
Fri May 2 16:21:33 CEST 2008
Martin v. Löwis wrote:
>> This leaves us with a few options:
>>
>
> 5. Reuse/Abuse Num(object) for arbitrary constants.
> AFAICT, this should work out of the box.
>
>
Eek. It *does* seem like Num would work out of the box, but would this
be a good idea?
What about *replacing* Num with Const? Might make optimizations
specifically for numeric values slightly hairier, and semantically I
think they might be different enough to warrant separate AST nodes
despite the similarity in implementation at the compiler level.
FWIW, I read Num as "numeric literal" and Const as "arbitrary constant",
but that's probably only because I've seen the immediate need for
constants with non-Num values in the process of writing the AST optimizer.
>> 1. A new AST expr node for constant values for types other than Str/Num
>>
>> I imagine this to be something like Const(PyObject* v), which is
>> effectively translated to a "LOAD_CONST v" by the compiler. This trades
>> the purity of the AST for a little practicality. A "Const" node has no
>> real source representation, it would exist solely for the purpose of
>> injecting PyObject constants into the AST.
>>
>
> I think this is the way to go. It doesn't violate purity: it is an
> *abstract* syntax, meaning that there doesn't need to be a 1:1
> relationship to source syntax. However, it is still possible to
> reproduce source code from this Const node.
>
>
I'm leaning toward this, too. It's dirt simple and quite clean to implement.
> I also don't worry about Jython conflicts. The grammar has a version
> number precisely so that you can refer to a specific version if you
> need to.
>
>
Any Jython folk care to weigh in on this? If there are no major
objections I think I'm going to forge ahead with an independant Const()
node.
Cheers,
T
More information about the Python-Dev
mailing list