[pypy-dev] W_XxxObjects

holger krekel hpk at trillke.net
Mon Jun 16 17:22:44 CEST 2003


Hello Samuele!

[Samuele Pedroni Mon, Jun 16, 2003 at 05:01:01PM +0200]
> At 16:41 16.06.2003 +0200, Armin Rigo wrote:
> >Hello Christian,
> >
> >On Sun, Jun 15, 2003 at 04:39:13AM +0200, Christian Tismer wrote:
> > > >It seems to me that the first implementation is a typical example of the
> > > >boilerplate kind of code that we hoped the project would remove, isn't it?
> > >
> > > It is the kind of code that *you* introduced into the project.
> > > Your new definitions seems to do an unwrap before calling the
> > > function. Or aren't they even wrapped?
> >
> >Sorry about that, I tend to write long confusing e-mails about subjects that
> >keep evolving a bit in my head. I will try to avoid that in the future
> >(probably just writing an e-mail, trashing it, and writing it again the next
> >day would be a good start).
> >
> >In that case the changes I proposed are not as big as they might seem. To make
> >it short, say for integers for example, they would just amount to defining
> >"W_IntObject = r_int", instead of a class with a single field which is an
> >r_int.
> >
> >So code like that:
> >
> >     def lt__Int_Int(space, i, j):
> >         return space.newbool(i < j)
> >
> >would work just because W_IntObject is r_int. There is no auto-unwrapping
> >magic; the r_int is the wrapped object -- as well as the unwrapped one, which
> >is I admit not much help in clearing the confusion. (It might thus not be such
> >a good idea -- although it would certainly be a boilerplate-reductor.)
> 
> If we want to reduce the boilerplate and avoid the confusion we should 
> really think in terms of auto-unwrapping.

Introducing the "w_*" convention was meant to un-confuse
interpreter-level and user-level objects :-)

In the above lt__Int_Int method there is another level of confusion IMO. 
One would think that when we evaluate the user level expression 

        1 < 2 

then this eventually dispatches a call to 

        lt__Int_Int(space, i, j)

which itself invokes 

        i < j

 ... leading to infinite recursion. Of course, it
doesn't but instead the "i < j" is typically performed as 

        space.unwrap(i) < space.unwrap(j)

thus resulting in a RPython operation of r_ints. Armin's example
above would again loose the object space instance  because the
"i<j" won't have the "space" context.  

IMO the challenge would be to introduce autowrap/unwrap without confusing
the programmer or reader of the source. currently, i consider

def lt__Int_Int(space, w_i, w_j):
    return space.newbool(space.unwrap(w_i) < space.unwrap(w_j))

as pretty well readable and not too much boilerplate. 

> But for a translated impl. wrapping/unwrapping won't be no-ops.  So the 
> code is probably clearer for the uninitiated as it is. If we want to reduce 
> boilerplate we should add some auto-unwrapping/wrapping logic where it can 
> make sense.

Which kind of contradicts your introductory statement but i agree :-)

cheers,

    holger


More information about the Pypy-dev mailing list