[pypy-dev] getting rid of multimethods?

holger krekel hpk at trillke.net
Wed Jun 16 22:52:59 CEST 2004


we just had a short IRC-discussion about the possibility of getting
rid of multimethods alltogether. 

Note [*], that during the EuroPython 2004-Sprint in Gothenburg we introduced
"descriptors" much as they are used in CPython.  This allows us to
cleanly expose "internal" objects like functions, code, module and frame
objects with e.g. proper __dict__ and __class__ descriptors.  Both the
standard and the trivial object space now work with descriptors (see
objspace/descroperation.py). The internal descriptors are defined in
interpreter/typedef.py.  As a side effect you can now run "py.py -S py.py"
i.e. pypy on the standard object space runs pypy on trivial object
space!  (Be sure to have recent hardware and/or make yourself
some coffee if you actually run this :-) 

However, "multimethods" are still used for building descriptors for
basic types.  The question arises if we still need multimethods at all.

If we wouldn't use them we would probably have to hand-code a few
type-switches inside e.g.  list-descr__setitem__ for slices and such but
those would be rather explicit and easier to understand than the
multimethod business (for me at least :-).  Any opinions? 

I think it's better to discuss this idea here on pypy-dev some more than
just on IRC ... 



[*] Sorry that there wasn't any EP2004 sprint report up to now.  I take the
    opportunity to quickly report about the main result of the sprint. 

More information about the Pypy-dev mailing list