Multiple dispatch again

[Samuele Pedroni]

"David Mertz" <mertz at gnosis.cx> ha scritto nel messaggio
news:mailman.1041666668.8010.python-list at python.org...
> "Samuele Pedroni" <pedronis at bluewin.ch> wrote previously:
> |> Is there a (good) reason for this change, or could it be an artifact
> |> of the alpha version?  I don't have 2.3 installed myself.
> |See
> |http://www.python.org/doc/2.3a1/whatsnew/node14.html
>
> OK, I read the thread at:
>
>     http://mail.python.org/pipermail/python-dev/2002-October/029035.html
>
> I can now say with absolute certainty that -single- dispatch fills me
> with Fear, Uncertainty, and Doubt.
>
> Since the BDFL has spoken, I assume 2.3 is going with C3 MRO.  But I
> don't like that.  I think it will be a wart for two reasons.  One is
> that--in contrast to the so-called "naive ordering"--you cannot explain
> C3 to anyone without making their brain explode.

You merge *preserving their order* the mros of the superclasses plus their
list.
If there are more choices privelege the mros of the superclasses
left-to-right.
If order cannot be preserved, give up.

+ Examples

> In a way, the
> consequences will be less surprising,

indeed most of the advantages of C3 can be shown through examples.

> but almost no one will be able to
> comprehend exactly what the rule is.

See above. For the irony value of it, nobody is still able to understand
what the 2.2 rule exactly was.

>  That doesn't match my idea of
> Python (it's not Lisp :-)).

It comes with the territory. Guido explains why we need some non-trivial
linearization (__setattr__ problem) and that we need such a thing is the
complexity issue.

>  In this case, I'd rather have something
> that is unintuitive at the margins than I would an exception.

you can voice for that on python-dev. Or for the other options not requiring
non-trivial linearizations:

- one could argue that the __setattr__ problem is really that with new-style
classes we do not have pure mixins anymore because everything has a (solid)
superclass. (I thought about this just more-or-less now). I don't know what
options this line could open.

- the Cecil route. That means a dispatch rule where only true subclassing
relationships are considered. All hierarchies go, but some method calls
would throw ambiguous dispatch exceptions.

regards.