[pypy-dev] Re: Extending the ObjectSpace Concept

Rocco Moretti roccomoretti at netscape.net
Tue May 20 06:04:21 CEST 2003

Armin Rigo <arigo at tunes.org> wrote:

>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

I think I may have not been clear on this point. I now think "controlling" is too strong a word. What I meant to imply is that the Spaces are the codification of abstrace concepts, and are on a somewhat equal footing in that regards. However, in an inheratance fashion, the ObjectSpaces are somewhat "superior" to either the Bytecode or SynataxSpaces in that you can swap out the Bytecode or SyntaxSpace without much change, if any, to the ObjectSpace, but if you rewrite the ObjectSpace, the Bytecode and SyntaxSpaces need updating to accomidate the change.

Where "control" comes in can somewhat be seen in the bootstrapping of the intrpreter. This is how I imagine it working (in pseudocode - method names are descriptive only):

#script is a file containing the script to run
w_str = ObjectSpace.to_string(script.read())

#ObjectSpace contains a reference to a SyntaxSpace to use to compile
# the string
w_code = ObjectSpace.compile(w_str)

#w_code is the script's code object
#ObjectSpace contains a reference to the BytecodeSpace to use to run
# this code object

The script is converted to an application level string first because I imagine we would want to write the compiler in the application level (and so the input string would need to be converted anyway.)

The ObjectSpace "controls" in that Bytecode objects and input Strings are Objects, and their semantics are controled by the ObjectSpace. (Part of those semantics being what happens when you run or compile those objects.)

>> 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).

Good point. An alterior motive in keeping the execution context explicit is that it eliminates that implicit global, and makes multiple threads less headache provoking. Is there a good way of keeping the execution context explicit?

Or another possibility: do we need to maintain the same execution context when calling implementing methods? (e.g. spawn a new execution context when starting the __hash__() method call.) I'm not too familiar with it, but I recall hearing that originally Smalltalk was to have the implementation of each object be in a seperate thread. (Hence the Smalltalk terminology "message passing" as opposed to "calling a method function".)

>> (...) __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").

Exactally. Except that for CPython, "builtin function objects" are written in C, and for PyPy, they can be written in either C or Python.

>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 ?

As I mentioned, I'm not tied to the names - they were just something to start from. That said, I do agree that "ExecutionSpace" does a better job of capturing the true sense of what they are than "BytecodeSpaces" does.

>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 ?

Sounds sensable. However, this proposal seems to go beyond reworking the internals and crosses into redesigning the user interface. (Which was something we were avoiding, if I remember correctly.) Properly reworked, though, it may be a worthwhile thing to change about CPython, at which point it isn't a redesign. Is this PEP material, or is it destined for a BDFL veto?


Try AOL and get 1045 hours FREE for 45 days!

Get AOL Instant Messenger 5.1 free of charge.  Download Now!

More information about the Pypy-dev mailing list