[pypy-dev] stdobjspace status

Armin Rigo arigo at tunes.org
Mon Feb 24 17:44:13 CET 2003


Hello everybody,

I've been progressing on putting the pieces together and will check-in my
changes as soon as possible.

The stdobjspace is getting ready to be tested together with the interpreter,
but is not quite there yet.  If someone (Michael?) can figure out a good
solution for the END_FINALLY problem, I'd love to hear it.  The problem is
that in a try:except: block, when we enter the except: part, there are some
control paths that reach the final END_FINALLY opcode (re-raising the
exception) and some that don't (caught exception).  It makes it hard to know
when we must remove from the blockstack the description of the potentially
re-raisable exception.

I was also thinking about the explicit multimethod registration in the
standard object space. For example, intobject.py contains the following code:

    def int_int_add(space, w_int1, w_int2):
        ...
    StdObjSpace.add.register(int_int_add, W_IntObject, W_IntObject)
    
    def int_int_sub(space, w_int1, w_int2):
        ...
    StdObjSpace.sub.register(int_int_sub, W_IntObject, W_IntObject)
    
    def int_int_mul(space, w_int1, w_int2):
        ...
    StdObjSpace.mul.register(int_int_mul, W_IntObject, W_IntObject)

I am proposing that it could be written with some more declarative idiom
abusing the 'class' keyword, something along these lines:

    class __multi__(W_IntObject, W_IntObject):
        def add(w_int1, w_int2, space):
            ...
        def sub(w_int1, w_int2, space):
            ...
        def mul(w_int1, w_int2, space):
            ...

It looks much nicer, I think, and it addresses a point raised during the
sprint (by Stephan if I remember right) about making the xxxobject.py files
less dependent on the actual name of their object space.  Indeed, the 'class
__multi__' code no longer mentions StdObjSpace.

This can be implemented using an original dispatching algorithm that has been
as far as I know invented for the Slate language (http://slate.tunes.org/).
The implementation of 'class __multi__(X, Y)' is defined to store the function
objects defined in the body -- here add(), sub(), mul() -- into *both* the X
and the Y class, into special-named attributes.  Performing dispatch to
'space.add(x,y)' is done by looking into the class of 'x' and the class of 'y'
to see if we can find the same function object in both.

More specifically, after a definition like

    class __multi__(X, Y):
        def f(x, y, extra):
            ...

we would have the function object 'f()' stored into each of the lists
'X.__dispatch_on_arg_1__' and 'Y.__dispatch_on_arg_2__'.  Then a call like
'f(x,y,extra)' looks up the types of 'x' and 'y' and searches for a function
object that would be present both in 'x.__class__.__dispatch_on_arg_1__' and
'y.__class__.__dispatch_on_arg_2__'.  What is nice with this approach is the
removal of the need for a central "repository" of functions, role which was
currently held by StdObjSpace.add.

BTW the new order of the arguments ('space' at the end) is such that
single-dispatch is a particular case of Python's original dispatch semantics,
with the argument we dispatch on being first (althought that original semantic
is also extended by the delegation stuff, e.g. delegating from 'int' to 'long'
for methods that fail to be implemented by 'int' for overflow reasons).


A bientôt,

Armin.



More information about the Pypy-dev mailing list