[pypy-dev] Re: Base Object library (was: stdobjspace status)

Christian Tismer tismer at tismer.com
Thu Feb 27 20:22:31 CET 2003


Hi Armin,

> On Thu, Feb 27, 2003 at 05:23:44PM +0100, Stephan Diehl wrote:
> 
>>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)
> 
> 
> 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!

Maybe I'm ignorant -- didn't read all of the
implementation, yet, but why is this a problem?
I don't think that RPython has anything to do
with Python constants and Python code objects,
and of course I think that creating code objects
should happen in user space. Then, the problem vanishes.

> So it seems that even code objects must be object-space dependent.  They would 
> be compiled by the application-level 'compiler' package inside of a given 
> object space, and not be 'extractible' from there.  The interpreter would only 
> unwrap the bytecode string, but not the tuple of constants.

I can't follow. Maybe the physical layout of structures
is different, depending of the object space, but
from the Python view, they are all the same.
If you marshal them, they are the same. Now think of
marshalled code objects, which you unmarshal from
the application-level. All the marshalled contants
will of course be turned into objects in the current
application space, however that is implemented.

Do we really use code objects from the "C" level
Python? This was a temporary hack, as I understood.
Of course cou can use them as a template, but I'm
assuming that we would transform them for the
"upper" world, before executing.

> If on the other hand we would prefer completely portable code objects, then
> they must contain "portable constant literals", including longs, and wrap()  
> must support at least these constants.  This could be nice, too, because we
> could then have object-space-independent bytecode repositories (like .pyc
> files).  But then we must include in RPython the notion of longs -- at least
> their existence, not necessarily any specific operation on them.  The same 
> about complex numbers.

I still see no reason why a long needs to exist in RPython
at all. Please, give me a hint :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



More information about the Pypy-dev mailing list