[pypy-dev] compiling "constants" (was: Base Object library (was: ...))

holger krekel hpk at trillke.net
Thu Feb 27 20:50:08 CET 2003


[stephan]
> About object instantiation:
> Where excatly is the textual representation of a python object turned into an 
> object? Is it done by the parser? (for example "12345L" --> 12345L)

It's the compiler and not the parser that turns "12345L" into
a Python object.  It executes "eval" on atom_number and atom_string
symbols (see compiler/transformer.py in the standard lib). 

[armin] 
> Damn.  I don't know.  If we don't include any 'long' type among our allowed
> RPython types (and we probably don't), then we will have to rethink the way
> code objects are currently completely put into interpreter-space level.  This
> cannot work if this code object contains constants of unknown types!

In CPython, the compiler package just uses the C-level "eval" to 
implicitely get ready-made "constant" Python-objects.  Thus it
avoids the problem of computing the constants by effectively handing 
it to its C-equivalent "compile.c" .  If we want to have a pure python 
compiler then we need to break the cycle (computing a constant requires 
computing a constant).

So for PyPy, the compiler package cannot use eval.  It should 
make a try-except dance trying to apply "int", "float", "long"
to atom_numbers and "str", "unicode" to atom_strings.  These
are builtin types we have to implement anyway and they will dispatch
to the appropriate objectspace internally.  Thus the compiler
could stay clean of infinite recursion and provide already wrapped
"constant" objects. 

So all in all, the compiler package is the right place to fix 
the "interpreter doesn't want to know types of constants" problem. 
Maybe the above sketched fix might even find its way into Python-2.3 
as it also speeds up and un-tricks the compiling process :-)

greetings,

    holger


More information about the Pypy-dev mailing list