Multiple dispatch again

[David Mertz]

"Samuele Pedroni" <pedronis at bluewin.ch> wrote previously:
|Damian Conway on his method:
|"some languages (e.g. CLOS) take a different approach -- breaking the tie by
|a recount on the inheritance distance of each argument starting from the
|left... In the author's opinion, this approach is appalling...

Where did you find this quote?  I don't think I saw it in the POD, but
maybe I overlooked it.

|If those are the worries then I would go the Dylan route: the applicable
|methods' signatures should be all comparable given the class precedence list
|of the arguments otherwise the dispatch is ambiguous.

I think for Python, both the Perl approach and the Dylan approach are
slightly wrong.  I guess my 'lexicographic_mro()' is essentially the
same as CLOS... which maybe leads back to that whole canard/thread about
Python being a Lisp dialect :-).

I think Conway's approach is very Perl-ish:  try to figure out what the
user was most likely to mean, than execute it willy-nilly.  In that
sense, he definitely does the -right- thing for the language the module
is in.  But Python doesn't make such assumptions.

On the other hand, Dylan seems much more bondage-and-discipline than
Python is.  Covariance/contravariance concerns, and generally an
obsession with type hierarchies, is not very Pythonic, IMO.  I wouldn't
say that raising a descriptive error in case of method ambiguities would
be totally contrary to a Python attitude... but I think better is a rule
which simply decides matters for every case, regardless of inheritence
fussiness.  lexicographic_mro() fills that criterion.

After all, plain inheritence in Python doesn't raise compilation/runtime
errors if the graph isn't pretty enough--as it does in some languages.
MRO never blows up.  Multimethod dispatch should follow that same
general attitude.

|So I think that a multi method dispatch mechanism should provide support
|for both approaches.

I think this remark is Pedroni, not Conway.  I wasn't positive what was
quoted.  But I agree with this.  I'll probably add some more
linearization functions--if only for demonstration.  The problem is just
to think of some that seem plausible.  I'm leaning towards
lexicographic_mro() as the right default one (not reverse_def(), which I
only used for compatibility with Tim Hochberg's original code).  But
options are nice.

Btw. Very nice example about ambiguities in weighted_mro().

Yours, David...

--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons.  Intellectual
property is to the 21st century what the slave trade was to the 16th.