[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