[pypy-dev] Code review possible?

[Samuele Pedroni]

From: "Armin Rigo" <arigo at tunes.org>
> 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.

a complete object space should cover ther story, yes, but I don't think you
have a working reimplementation of all the semantics of typeobject.c for
example ... my point is that that was more difficult/important than how to
write listobject impl.

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

up to the translation as anything else <.5 wink>.

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

I doubt it, as long as things are defined in terms of the __add__/__radd__
dance for user objects.