[pypy-dev] Code review possible?

[Armin Rigo]

Hello Samuele,

On Sun, Mar 02, 2003 at 08:48:56PM +0100, Samuele Pedroni wrote:
> ...
> funcobject.c
> moduleobject.c
> etc
> 
> that means the glue and skeleton of the object model/runtime; I don't think
> object spaces as such cover already the whole story,

Well, they should cover the whole story apart from the actual translation 
process, which is I admit a big open point. OTOH object spaces are also the 
correct place to include special-case translations or translation code about 
specific object space files, e.g. multimethod.py or Christian's r_int.

> OTOH if for the first try the implementations of int,long,dict,tuple... are
> simply wrappers around the CPython types, is not too much a problem because
> local to the single object types and the details are fixable and one can
> solve the problem one object type at a time.

That was the idea.  The cpythonobject.py is just that.  It is quite incomplete 
in that it will not let most operations pass throught the underlying object 
(so it's more of a black box right now).

> But if don't know how to get 1 .__add__ to behave or lookup/dispatch in
> general or the content of type("").__dict__ etc right, that's a FAR more
> serious obstacle.

I don't think getting this right should be too difficult. Even in CPython it 
is kind of a hack that makes it work on top of the standard types. A suitable 
restriction would let us implement 1.__add__ as in CPython. On the other hand, 
this is a kind of "tricky" behavior in CPython (is it completely formalized in 
the language reference?) which may go away at some point because the original 
idea was still that a.__add__(b) should eventually be the same as a+b -- 
unless I'm mistaken here.


A bientot,

Armin.