[pypy-dev] W_XxxObjects

[holger krekel]

[Armin Rigo Mon, Jun 16, 2003 at 05:09:27PM +0200]
> Hello Holger,
> 
> On Sat, Jun 14, 2003 at 08:16:52PM +0200, holger krekel wrote:
> > Interesting. But the second example should still be
> > 
> >     def lt__Int_Int(space, i, j):
> >         return space.newbool(i < j)
> > 
> > because using builtins in restricted python should be avoided, shouldn't it? 
> 
> Not necessarily. See again
> http://codespeak.net/moin/pypy/moin.cgi/RestrictedPython, "builtin functions".

Hmmm.

> > Especially in the presence of multiple object spaces this would loose
> > context.
> 
> No context is needed. The built-in functions we are using here are the real 
> low-level essential stuff, at the same level as the " < " operator between 
> RPython's integers.

But when you want to auto-unwrap (which your above example seems to
imply) how do you do that? 

> These have nothing to do with the functions redefined in module.builtin*; the 
> list of built-in functions we allow in RPython is restricted, and how you use 
> them too, so that they are no burden to the translator. Still, they are 
> nothing more and nothing less than all other operator: we allow some, and 
> disallow some.

Sure. I just thought it's clearer to say RPython avoids "builtins"
alltogether but uses explicit references. E.g.

    def lt__Int_Int(space, w_i, w_j):
        i,j = space.unwrap(w_i, w_j)  # returns a tuple 
        return space.newbool(RPY.lt(i, j))

Thus making it very explicit that there is a "change of level". 
Then again, for all basic RPython types we could easily dynamically
generate the above kind of multimethods reducing the need for repetitive
functions completly.  e.g.

for op in ('lt','le','eq','ge','gt'):    
    for typ in (W_StringObject, W_IntObject, ...):
        def tmp_op(space, w_i, w_j):
            i,j = space.unwrap(w_i, w_j)  
            rpy_op = getattr(RPY, op)
            return space.newbool(rpy_op(i, j))
        getattr(StdObjSpace, op).register(tmp_op, typ, typ)

would reduce boilerplate quite a bit. Probably we would like
to make something like this another "tool" function which can 
be invoked from intobject.py, stringobject.py like

    register_rpython_adapter_operators(W_IntObject), 
        "lt", "le", "eq", "ne", "ge", "gt")

or so. 

> > But the W_XXXObject is also used as a tag for a specific implementation of a
> > type. IOW there is no 1:1 relationship of W_XXXObject and W_XXXType,
> > right?
> 
> The names are misleading. There is one W_XXXType, but there might be a lot of 
> classes implementing it. The existence of one particular such class with the 
> exact name W_XXXObject is misleading. What I was suggesting was that a small 
> number of these specific W_XXXObject classes might be equal to a restricted 
> Python type instead of being a class at all.

OK, understood (hopefully). 

> > It seems to me that "restricted python" is largely vapor-ware so i have
> > problems following.  Or am i missing something? 
> 
> This is a most interesting point. I think that trying to actually get
> somewhere in this direction could be a subject of the upcoming sprint. The
> first sprint was (very roughly) the interpreter, the second sprint the
> stdobjspace, let the third one be the third main missing piece of the puzzle
> :-)

sounds like a large design discussion unless you again bring some brilliant 
new idea to the sprint :-)

Btw, apparently all of Pyrex is implemented in Python and generates
C-files which will compile and bind against CPython. It seems to
have its own Compiler (written in Python). 

Wouldn't using Pyrex as a starting point for implementing/generating 
"RPython" make sense?  Later on, we could try to make a PyPyrex which 
generates stand-alone C-files. At least it would again boost the 
"nestedness" of PyPy :-)

Without this starting point i am skeptical for our four-day sprint 
to provide enough time for coming up with C translators/generators etc. 

cheers,

    holger