[pypy-dev] stdobjspace status

Christian Tismer tismer at tismer.com
Mon Feb 24 18:51:18 CET 2003

Armin Rigo wrote:

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

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

Hmm, "deriving" from the same class twice doesn't
look very clean, and space at the end, and no
"self", hmm hmm.

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

I agree that this is an advantage.


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

Well, I see that class __multi__ should have a special
meta-class, in order to behave as you like?
Or is it just a placeholder, interpreted by something

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

I don't get why spae at the end is an advantage?
Just for not pretending to be something like "self"?

Please give me an example how I would change my
intobject implementation.
Do you mean that instead of the single functions,
I should put together such a __multi__ class?

The current way of doing things was not so bad,
since we had a defined interface which operations
exist. How should it be done without
      StdObjSpace.add.register(int_int_add, W_IntObject, W_IntObject)

Also, how about sticking with one agreed interface for,
say, at least two weeks and have more objects
implemented? I'm not happy to change tested code
all over again. At least, with the current frequency
of design changes, I'm a bit reluctant to do anything
on IntObject.

ciao - chris

Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/

More information about the Pypy-dev mailing list