[Python-Dev] Python-dev Summary for 2002-10-01 through 2002-10-13

[Samuele Pedroni]

From: "Brett Cannon" <bac@OCF.Berkeley.EDU>
> =================
> `perplexed by mro`__
> =================
> __ http://mail.python.org/pipermail/python-dev/2002-October/029035.html
>
> Splinter threads:
>
> Re: my proposals about mros (was: perplexed by mro) :
> http://mail.python.org/pipermail/python-dev/2002-October/029167.html
> C3 implementation :
> http://mail.python.org/pipermail/python-dev/2002-October/029230.html
>
> Samuele Pedroni said he was "trying to wrap [his] head around the mro
> computation in 2.2".  Apparently there is the algorithm mentioned at
> http://www.python.org/2.2.1/descrintro.html (dubbed the naive algorithm)
> and then the one implemented in typeobject.c_ (called the 2.2 algorithm).
> Samuele discovered some inconsistencies with the implemented algorithm
> that he desired some explanation about.
>
> Guido responded, thankful that someone was giving this a look because his
> "intuition about the equivalence between algorithms turned out to be
> wrong".  Guido stated that he thought that he wrote the algorithm from the
> book "Putting Metaclasses To Work" correctly sans raising an error when
> major conflicts occur in the ordering.  In a later email Guido explained
> that the naive algorithm came about by his attempt to simplify the
> explanation of the 2.2 algorithm.  Guido pretty much wrote the algorithm
> from the aforementioned book.  Now the algorithm is not simple, so Guido
> did his best to simplify the explanation.  Unknowningly, though, he came
> up with a variant on the algorithm in his explanation.
>
> Greg Ewing pointed out that he thought the naive algorithm was nicer since
> it seemed to work more intuitively and was easier to explain (and remember
> kids, these are basic tenants in Python programming).  Guido ended up
> stating that "If Samuele agrees that the naive algorithm works better,
> [Guido will] try to make it so in 2.3".  Well, Samuele said that the "2.2
> mro is the worst of our options".
>
> There was a problem, though, with the naive algorithm; it is not monotonic
> as pointed out by Samuele.  This led him to put out two options:
>
> 1. Use the naive algorithm, which had the drawback of being monotonic.

s/being/not being/

> Samuele also believed that it didn't produce "the most natural results".
>
> 2. Adopt C3_ as described at
> http://www.webcom.com/haahr/dylan/linearization-oopsla96.html and
> apparently used by Dylan_ and Goo_ .

only by Goo. Dylan uses stilll a different algorithm with results more similar
to those of the one used by CLOS, but I don't think that's important. They are
all described in the paper. Dylan would have adopted C3, but it was switching
algorithm aftering starting with the CLOS one and having already code around.

> This algorithm is monotonic and
> Samuele says is more intuitive.

more intuitive in its results.

> Guido got around to reading the C3_ paper and agreed that "we should adopt
> C3".

>  He thought that the 2.2 algorithm was like the C*[LOOPS] algorithm
> mentioned in the paper.

there was a typo, it's L*[LOOPS]. Btw, we still don't know exactly, it's
probably a variant, and I don't think it's so relevant.

> Samuele then wrote a C implementation of the
> algorithm.  Guido said he would get to the patch after 2.2.2b1 got out the
> door.
>
> .. _C3: http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
> .. _Dylan: http://monday.sourceforge.net/wiki/

if the reference to Dylan goes away above, this one should also go away.
Otherwise I would use

http://www.gwydiondylan.org/

as reference URL for Dylan or simply comp.lang.dylan .


> .. _Goo: http://www.ai.mit.edu/~jrb/goo/manual.43/goomanual_55.html
>
> .._typeobject.c:
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Objects/t
ypeobject.c

regards.