On Tue, Aug 26, 2008 at 5:32 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > What I would really like to see is a fourth blog entry that shows > how to use super() reliably and correctly.
That could be arranged. > In general, I opposed > to creating documentation in the form of "danger, danger this > could explode ...." IMO, there is not much point in dwelling on > bugs that have already been fixed, nor is there an advantage to > showing all the ways the tool can be misused. Yep. The parts about the bugs of super in 2.2 and 2.3 were written years ago, when they were relevant. Nowadays they are less relevant, but since they were already written and since there are still people using older versions of Python I decided to keep them. I would not keep them in a revised version intended as "semi-official" documentation of super. Still, I think they are fine as a blog post. > For cooperative multiple inheritance, I take issue with the abstracted > examples provided (i.e. inconsistent signatures). In a real app that > actually needs cooperative multiple inheritance, it becomes self-evident > what "cooperative" actually means -- the methods *have* to be > designed to interoperate -- it is intrinsic to the problem at hand. > Cooperative multiple inheritance is *not* about mixing two unrelated > parents that just happen to use the same method name but have > different semantics and were not designed to cooperate with each other. > > The A-B-C-D diagrams and foo/bar methods in the examples are > deceptive because they silently drop the precondition of cooperation > while attempting to demonstrate a supposed flaw in the tool. They just show that the tool is delicate and not easy to use. > If I understand the problem correctly, in the rare cases where you do > need cooperative multiple inheritance, then super() is the only workable > solution short of designing some equivalent using composition instead > of inheritance. In my experience, one can go a long way using composition instead of inheritance. I also think that Python would not lose much without cooperative multiple inheritance. This is however a personal opinion and in any case the point is moot because the language is the way it is. Still, in a blog post personal opinions and even rants have their place. That part could be removed in an "semi-official" document. > Also, it may be controversial, but there may be some merit in de-documenting > the "unbound" case. It seems to add more confusion than it's worth. Fine with me. > Lastly, I take issue with one other part of the blogs. While they show > a clear dislike for cooperative multiple inheritance, they take a potshot > at multiple inheritance in general. I don't follow the logic here. IMO, > mixin classes like DictMixin have proven themselves as being very > useful. Plenty of frameworks share this approach. Likewise, the > new ABCs offer mixin capabilities that are really nice. > > I think it is a non-sequiter to reason from "diamond diagrams are > complicated" to "mixins should be disallowed". Instead, I think it better > to simply recommend that a key to happiness is to keep various mixin classes > completely orthogonal to one another (no overlapping method names). I not completely against multiple inheritance. I am against multiple inheritance as it is now. A restricted form of multiple inheritance in which mixins classes are guaranteed to be orthogonal would be fine with me (provided it is not abused). This concept exists already in other languages, the orthogonal mixins are called "traits". I have written a trilogy of papers about mixins: if you read them, you will see where I come from (Zope, which I do not like) and you will also see that I like DictMixin instead. I will publish the papers in the blog soon or later, but you can find the Italian version here: http://stacktrace.it/articoli/2008/06/i-pericoli-della-programmazione-con-i-mixin1/ http://stacktrace.it/articoli/2008/07/i-pericoli-della-programmazione-con-i-mixin2/ http://stacktrace.it/articoli/2008/08/i-pericoli-della-programmazione-con-i-mixin3/ Michele Simionato _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
