[Python-3000] Adaptation vs. Generic Functions

[Samuele Pedroni]

Guido van Rossum wrote:
> One followup. Alex mentioned that PyPy used to have its own
> implementation of multiple dispatch (which is really the same as
> generic functions) but ditched over a year ago. Would Armin or Samuele
> care to explain why? Do they no longer like multiple dispatch or was
> the reason for the extraction specific to PyPy?
> 

No, PyPy is still using multi-methods, both in the translation chain
and in the Python implementation itself. They are both implementation
details, we are not offering at the moment user-level multimethods.

In the translation chain itself we use a simple 2 argument multiple
dispatching based on a pairtype metaclass:

http://codespeak.net/svn/pypy/dist/pypy/annotation/pairtype.py

both for annotation (our type inference): (example)

see

class __extend__(pairtype(SomeObject, SomeObject)): ...


etc. in http://codespeak.net/svn/pypy/dist/pypy/annotation/binaryop.py


and the part of the translation that converts high-level operations to
low-level operations: (example)

see

class __extend__(pairtype(StringRepr, SliceRepr)): ...

class __extend__(pairtype(StringRepr, StringRepr)): ...


etc. in http://codespeak.net/svn/pypy/dist/pypy/rpython/rstr.py

For this kind of code multi-dispatching is very natural.


For the interpreter itself we use a form of general
asymmetric multi-dispatching, implemented at the moment
as chained double-dispatching although other strategies are possible,
for the special methods implementations (what in CPython would go in the
type table slots). I think the difference Alex is referring to is that
at some point we were exposing the multimethods as __xxx__ directly, but
this didn't match descriptor and Python semantics properly, so we moved
to expose as __xxx__ restrictions of the multimethods on the relevant
part of the hierarchy.

We use multimethods for implementing Python types behavior because
it makes easy to have multiple inter-operating internal implementations
appearing as the same user level type
(this should make it simple for example to have integers implemented
as both short tagged integers and normal boxed ones for larger ones,
or to even include long integers under the "int" type).

About multi-dispatching, when I suggested switching to C3 for the mro,
it was also because it's a good basis for multi-dispatching (it was
developed in such a context).

In Python is relatively easy to roll your own multi-dispatching when you
need it. It Is also true that languages offering multi-dispatching
usually offer rather sophisticated versions of it, because it is natural
to need to tweak dispatching in practice, or go for very general forms
like predicate dispatching.

As a side note I think, while multi-dispatching makes sense as
a language design level addition, adaptation feels more like
a software engineering/library level tool.

regards.