[pypy-dev] Extending the ObjectSpace Concept

Rocco Moretti roccomoretti at netscape.net
Sun May 4 22:17:34 CEST 2003

I think it may be worthwhile to extend the concept of Object Spaces to the 
bytecode and sourcecode levels. (Provisional names: BytecodeSpace and 
SyntaxSpace.) Just as an ObjectSpace embokdies the abstract concept of the 
semantics of objects and their interactions, a Bytecode space embodies the 
concept of the bytecode and its effect on execution flow control. 
Likewise, a SyntaxSpace embodies the abstract concept of the textual 
program and its mapping onto bytecode and object definitons.

Now, these spaces are distinct, but they are not independant. The 
SyntaxSpace needs to know which BytecodeSpace and ObjectSpace to use to 
output functions and objects, a BytecodeSpace needs to know what 
ObjectSpace to use to implement object interactions, and an ObjectSpace 
needs to have some idea about SyntaxSpaces and Bytecode spaces so that it 
can compile strings and execute functions.

As I imagine it currently, the ObjectSpace will be the controlling space. 
A string or file is given to the ObjectSpace to execute. It passes the 
string to the SyntaxSpace, which then compiles it into a number of 
ObjectSpace objects, including module, function and code objects. The 
object space then executes those functions by passing them to the 
appropriate BytecodeSpace. In the process of execution, the BytecodeSpace 
then calls back to the ObjectSpace to implement the object semantics.

Note that there is a distinction between BytecodeSpaces and the an 
ExecutionContext, in that each BytecodeSpace would have singleton 
semantics, but there can be multiple different ExecutionContexts. (Perhaps 
it could be as simple as a class/instance distinction.) Perhaps the 
Bytecode/Syntax Spaces don't need to be actual entities, but could stay as 
abstract concepts.

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 

Which sort of leads me to the reason I got on this train of thought. Over 
the past couple of weeks I've been trying to fix the remaining bugs in the 
trivial object space. Some of them seem to stem (at least in part) to the 
lack of a separate sys/builtins module for the application level code. (As 
was mentioned earlier by mwh). I've attempted to fix it by special casing 
the builtin __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.

As I see it, there are two simultaneous execution "threads" running 
through the interpreter. The host interpreted "interperter level" 
functions, and the pypy interpreted "application level" functions. The 
host interperter takes care of the first, so I'll deal with the second. 
You can split the application level functions into three categories:

Application Space Functions: Python functions which should be run under 
the pypy interpreter. (i.e. User code)

Interpreter Level Python Functions: Functions written in Python which need 
to be run on the host interpreter. These are functions which are called 
from and return to user code. (Like a special cased __import__()).

Builtin Functions: Compiled code, to be run on the processor itself.

Currently, we don't make a distinction between the two types of Python 
functions - we do exclusively Application Level functions. To do this we 
need to distinguish between the two.

Therefore I propose that even in the TrivialObjectSpace we have special 
function objects. These can be just a simple wrapper around the host 
function objects to mark them as Application Level functions, as opposed 
to the unwrapped Interpreter Level functions. I think the wrapping can 
easily be accomplished in the MAKE_FUNCTION opcode.

Does any of this sound reasonable? I tried to explain it well, but I'm 
quite sure I failed, so if you have any questions, please ask. 


Try AOL and get 1045 hours FREE for 45 days!

Get AOL Instant Messenger 5.1 for FREE! Download Now!

More information about the Pypy-dev mailing list