[Python-Dev] Re: Multimethods (quelle horreur?)

Samuele Pedroni pedroni@inf.ethz.ch
Sun, 18 Aug 2002 01:01:18 +0200


From: David Abrahams <dave@boost-consulting.com>
> >  [T3==T2 case corresponds to the above
> >
> >  A.meth = foo
>
> I hope you are covering this case just for generality's sake. It's easy
> enough to forbid.

Yes, but Python is a dynamic language, you should allow
for redefinition in some way.

> >  the idea is to allow optionally to specify together
> > with an argument a supertype of the argument and to have
> > the dispatching mechanism use the supertype instead
> > of the type of the argument for dispatching:
> >
> > gf(a,b,_redispatch=(None,SuperTypeOf_b))
> >
> > the dispatch mechanism will consider the
> > tuple (type(a),SuperTypeOf_b) instead
> >  of (type(a),type(b)) for dispatching.
>
> More "sugarily:"
>
>     gf(a, dispatch_as(b, SuperTypeOf_b))
>
> Interesting. Not sure how I feel about this.
>
> >  This is the moral equivalent of
> >  single dispatching:
> >
> >  SuperTypeOf_b.meth(b)
> >
> >  or super(SuperTypeOf_b).meth(b)
>
> Hmm. OK, I see the analogy. I hardly ever have to do that even in the
> single case, but I get what you're up to.

more than as a super, it can be useful if you are picky
about ambiguities.

> >  you get the same effect as multidispatching
> >  simulated through chained single dispatching.
>
> That seems a bit arbitrary, but I guess there are other precedents in
> Python for an arbitrary ordering (e.g. ordering on type names for
> heterogeneous object comparison).

Yes, e.g. the mro used for single dispatch in case of multiple
inheritance.

The other option is to totally refuse ambiguity.
Which is also reasonable.

Honestly there is no big agreement about whether
automatically solving ambiguities is a good thing in
general (even for the single dispatch case).

See for a short opinionated survey:

The Cecil Language
Specification and Rationale

Craig Chambers

2.7 Method lookup
2.7.1 Philosophy

http://www.cs.washington.edu/research/projects/cecil/www/Refman/wmwork/www/ceci
l-spec_12.html#HEADING38

The predictability depends not only on
 the rule but also on the
complexities of the class hierarchies at hand,
especially in the presence of multiple inheritance.

For the stuff  I tried with my multimethods
impl, it seemed that the CLOS rule made
sense, and getting ambiguities seemed
more an impediment. As I said it corresponds
to chained single dispatch and that was basically
what I needed in sweeter way.

Anyway this can be made configurable
for the single gf.

regards.