[pypy-dev] Extending the ObjectSpace Concept

[Armin Rigo]

Hello Rocco,

(Firstly, sorry for the lack of answers to your contributions; you seem to be
the most active person on pypy right now...)

On Sun, May 04, 2003 at 04:17:34PM -0400, Rocco Moretti wrote:
> I think it may be worthwhile to extend the concept of Object Spaces to the 
> bytecode and sourcecode levels. (Provisional names: BytecodeSpace and 
> SyntaxSpace.)

Ok. It makes sense. I should write a bit more about what I intended to use
ObjectSpaces for, though, and see how explicit Bytecode/Syntax spaces fit in
the picture. I promize I'll. In particular, I don't think about ObjectSpaces
as controlling spaces, as you do, so there is some idea matching to do there
:-)

> If accepted, one change that should be made is to shift the function call 
> semantics in the object space to have an explicit execution context as a 
> parameter, so that it is clear that the ObjectSpace is controling 
> execution.

That's not clear, because almost any other operation could indirectly do a 
function call (e.g. hash() calling the class' __hash__() method).

> (...) __import__(). However, in order to do so, __import__() needs 
> to be able to call out to interpreter level python functions. With the 
> current TrivialObjectSpace, that's impossible as all python functions are 
> run through the pypy interpreter.

Yes; we miss a way to call interpreter-level functions from
application-level ones (the CPython's "builtin function objects").

We could take a broader point of view here, and use the separation between
function objects and code objects. We could have several types of code
objects, each one corresponding to a kind of function that you list:  
bytecodes, built-in (i.e. interpreter-level), compiled machine code... The 
(single) function object type would have the role of the interface, allowing 
introspection -- which is a nice thing to have, CPython's built-in functions 
lack that -- whereas the various code object types would correspond to the 
various ways of implementing a function. Come to that, these ways could be 
tied to various BytecodeSpaces -- a concept we could rename ExecutionSpace, 
maybe ?

Executing a function object would then be done by collecting the arguments
based on the signature (which would be published in the function object),
which would result, say, in a single dictionary (the "locals"); then we call
"f.func_code.execute(globals, locals)".

What do you think about it ?


Armin