[Python-3000] Builtin iterator type

George Sakkis gsakkis at rutgers.edu
Thu Nov 16 07:32:36 CET 2006


On 11/16/06, Talin <talin at acm.org> wrote:

> As far as multiple dispatch goes: I would agree here as well, especially
> when we talk about binary operations. For example, suppose we have two
> objects, a and b, which are of types A and B respectively. And suppose
> each of those types overloads both __add__ and __radd__:
>
>    class A:
>       def __add__( self, other ):
>          ...
>       def __radd__( self, other ):
>          ...
>
>    class B:
>       def __add__( self, other ):
>          ...
>       def __radd__( self, other ):
>          ...
>
>    a = A()
>    b = B()
>
>    print a + b   # __add__ wins over __radd__, but should it?
>    print b + a
>
> My conclusion: Single dispatch systems are a poor way to specify
> operator overloading. Compare this to the corresponding generic dispatch
> case:
>
>     @generic( A, A )
>     def __add__( p0, p1 ):
>        ...
>
>     @generic( A, B )
>     def __add__( p0, p1 ):
>        ...
>
>     @generic( B, B )
>     def __add__( p0, p1 ):
>        ...
>
>     @generic( B, A )
>     def __add__( p0, p1 ):
>        ...
>
> With multiple dispatch, its easy to spell out what will happen in each
> possible permutation of arguments - and if you get an ambiguity, the
> dispatcher will let you know about it, instead of simply choosing an
> implementation arbitrarily.

Interesting idea, certainly not mainstream for the moment though.
Short question: how do multiple dispatch systems deal with the
combinatorial explosion ? I guess there should be a way to avoid
having to spell out all combinations every time, or it will soon be
unpractical.

George


More information about the Python-3000 mailing list