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. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
