[pypy-dev] Multimethods again

Armin Rigo arigo at tunes.org
Fri Feb 27 17:15:52 CET 2004


Hello Christian,

On Thu, Feb 26, 2004 at 06:12:22PM +0100, Christian Tismer wrote:
> I like the idea very much! Can we adopt this for pypy?
> Highly elegant.
> Also it appears to be quite efficient.

It´s worth thinking about.  There are actually variations on the idea that
I´ve been playing around for other uses as well, like context-dependent
methods on objects.  For example, suppose that we have a class R_Int in the
translator for "Python integer".  This one would be pretty generic, created by
the annotation analysis.  Then we need to translate it, either to C or to
Lisp.  This would be best done with methods on R_Int like get_c_type(),
define_c_variable(), etc., and the same for Lisp.  It is not elegant to have
all these methods added to the pretty general and translation-independent 
class R_Int, but it is a burden to have to use isinstance(x, R_Yyy) all the 
time.  So we could have a "view" class with a special meta-class:

class CWriter(View):
    pass

class __view__(CWriter, R_Int):
    def get_c_type(self):
        # self is here an R_Int instance
    def define_c_variable(self):
        etc.

To be used as:

    CWriter(x).define_c_variable()

So CWriter(x) is similar to pair(x,y) in the multimethod example, with just
one argument in this case: it means "a proxy object around x whose type is the
one defined by the class __view__(CWriter, x.__class__)".

This can have numerous usages, e.g. for the awful pypy_xxx methods that some
built-in classes have (PyFrame, PyCode, etc.).


A bientot,

Armin.



More information about the Pypy-dev mailing list