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

[holger krekel]

[Christian Tismer Thu, Feb 27, 2003 at 08:22:31PM +0100]
> 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.

Agreed.  Creating code objects at application-level needs
some tweaks, though (see my other post, same thread). 
 
> > 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.

Marshaled (pypy-) code objects would need to serialize 
objectspace dependent types.  Maybe we should require all 
objectspaces to implement interoperable serialization.  
This would also provide a means to transfer objects from 
one objectspace to another (and to CPython). 

However, I am a bit uneasy about tying pypy too deep to 
CPython's codeobject layout.  We are likely to want to 
extend/modify it the future anyway.  So maybe we shouldn't
take CPython-comptability down to the code object .  
It's the "heart of gold", produced by the compiler and 
driving the interpreter.  These are areas where we want 
maximum flexibility and thus shouldn't think too much 
from CPython's code object which really is more of
an implementation detail than anything else. 

just my 2ec, 

    holger