[pypy-dev] Object model

[Rocco Moretti]

Armin Rigo <arigo at tunes.org> wrote:


>Now I believe in following the idea that CPython's main loop does not assume
>anything at all about the PyObjects it manipulates, but does every operation
>via calls to library functions like PyNumber_Add().  All it does is moving
>PyObjects around, mainly between the stack and the locals.  Similarily, our
>own main loop should not assume anything about the objects it stores in the
>stack and the locals, not even that they have some well-known methods.
>Instead, we would provide it with the equivalent of PyNumber_Add() & co.

I was originally going to say I thought the general-dispatch-function and 
the standard-object-method-interface options were practically equivalent, 
but I changed my mind.

The reason lies along the concept of multi-methods. (I think that's the
right term - functions are polymorphic not just on their first argument
(the parent object), but on all arguments.) This may not make much 
difference on most operations, but it facilitates arithmatic conversion. 
If we're adding two numbers, we can handle the conversion code in the 
general Py_NumberAdd routine, instead of spreading it out to the functions 
implementing float and integers and rationals etc.

...

> * wrap(a), taking a *normal* object and putting it into a black box.  Its
>what the interpreter does for a LOAD_CONST, for example: it has a real Python
>object and wants to send it to the object space.  For example, if the object
>space has a custom implementation "class MyList" for lists, then wrap([1,2,3])
>should create a MyList instance.

I wonder whether wrap() and unwrap() are really nessasary - they seem to 
blur the distinction between interpreter-level and application-object-
implementation-level.

It seems to me that the LOAD_CONST issue woold be better dealt with by 
having the compiler/function loader create the black box objects 
themselves, instead of there being a run-time translation between 
interpreter-level objects and application-level objects. 

> * unwrap(x) is the inverse operation.  Used by the interpreter in the rare
>cases where it really needs to observe the object.  For example, for a
>conditional jump, after it obtained the truth-value with (say) a call to the
>truth() method, it must pull the result out of the object space to know
>whether it is really False or True.

But how would we handle it if we wanted to redefine what was 
considered "true"? A generic unwrap couldn't tell what the unwrapped 
object is being used for.

A better way of implementing it would be to look at the specific cases 
when the interpreter machinery actually cares about the value of the black 
box object. In the case of conditional branching, it might be best to 
define a standard function in the ObjectSpace which takes a black-box 
application-level object and returns an interpreter-level object 
representing the truth value. (Not a generally "unwrapped" object, 
specifically 0 or 1 - or rather interpreter-level True and False, depending on how compatible we want to make the the PyPython codebase.) 

>Looks like a cool point of view, doesn't it ?

Very much so, and it interfaces well with the concept of being able to 
hot-swap bytecodes. (Not only can you change the bytecode semantics of the 
processor, you can also change the object semantics.)

But-first-we-need-a-working-implementation...
-Rocco

__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/