[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