4 May 2003 22:17
Extending the ObjectSpace Concept
Rocco Moretti <roccomoretti <at> netscape.net>
2003-05-04 20:17:34 GMT
2003-05-04 20:17:34 GMT
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.(Continue reading)
[...]
> 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.
No, your description of the problem and solution made much sense over
here.
Are you coming to the sprint in May?
Cheers,
M.
> 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
RSS Feed