[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