[pypy-dev] Extending the ObjectSpace Concept
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
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