[Python-Dev] Python-dev Summary for 2002-10-01 through 2002-10-13 (original) (raw)

Samuele Pedroni pedronis@bluewin.ch
Sun, 13 Oct 2002 17:22:19 +0200

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/goomanual55.html

..typeobject.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Objects/t ypeobject.c

regards.