hermy wrote: > Thanx, I think I got it (please correct me if I'm wrong): > o super(C,self) determines the next class in the inheritance hierarchy > according to > method resolution order, and simply calls the specified method on it > (in this case > __init__ with the specified argument list. > o since I cannot now beforehand where my class will appear in the > inheritance > hierarchy when __init__ is called, I need to pass on all the > arguments and let > my method decide which ones to use. > > On the other hand, when I use old-style, s.a. B.__init__(args), I > specify statically > in which class the method lookup should occur. > > Unfortunately, new and old style don't mix well (as I found out by > experimenting a little), > so for new code I should probably stick to new style, and use super.
Well I wasn't suggesting you mix styles; I was suggesting all old, all the way here. With due care, the effect of using this style over the entire hierarchy is to call the __init__ functions possibly out of MRO sequence. You have to pay some attention to what methods are called in __init__ anyways, so this isn't exactly a whole new dimension of carefulness. > Which leads me to my original problem. Your suggestion with **kwargs > works fine, > but only if it's used consistently, and I'll probably need to do some > name-mangling > to encode class names in parameter names in order to avoid name > clashes. Meh. Do nameclashes happen so often that it's better to implement a handmade name mangling scheme rather than just change a variable name when one pops up? > Unfortunately, this solution is (as far as I know) not universally > accepted, so if I want > to multiply inherit from other people's classes (who didn't follow this > solution), it won't > work. Short: I can make it work if I write all the classes myself, I > can't make it work if > I try to re-use other people's code. I would suggest that, if you're trying to make a mixin of completely different classes, super is only one of many worries. There's all sorts of things that could go wrong when you do that in Python. When you have a class that's not expecting to be in an inheritance hierarchy, it might not even be calling super. Or if it's a derived class, it might be using old-style calls to the subclass. Sometimes classes have incompatible C-footprints and can't be mixed in. Python objects use a single namespace for their instance variables, so if these two classes happen to use the same for a variable, you're pretty much out of luck. If any of the classes use a different metaclass there could be all sorts of problems. Bottom line is: if you're going to multiply inherit from two classes, they have to cooperate in some fashion. You have to be careful, and sometimes you can't avoid modifying the base classes. (Yes, you can do that.) > Which is a pity, since this means that I can't even use multiple > inheritance for mixin > classes (where I know that no diamond will appear in the hierarchy, and > I have a simple > tree - except for the shared object superclass). Um, sure you can. You can't necessarily, but it doesn't mean you can't never. > So, for the moment my conclusion is that although Python has some > syntax for > multiple inheritance, it doesn't support it very well, and I should > probably stick to > single inheritance. "well supported" is a relative term. I don't disagree that MI can be unwieldy in Python, but it seems to me that throwing it out of the toolshed is a bit extreme here. There's just times when MI is the best and most elegant solution to a problem, and not using it because you have to fiddle with __init__ args a little is probably not a good thing. > Also, if there would be some language support for the argument passing > problem > (especially for __init__ methods), multiple inheritance would work just > fine. Hopefully > some future version of Python will solve this. Not likely at all. I think the Python philosophy is that MI is a thing that's occasionally very useful, but not vital. I think the designers feel that a little unwieldiness in MI is a small price to pay compared the language changes needed to take away that unwieldiness. For instance, a foolproof way to avoid name clashes in mixin classes would require a complete overhaul of namespaces in Python, and that is not going to happen. At best, what you might get is some sort of protocol (maybe a decorator) that standardizes calling the base class methods, coupled with a very strong suggestion to use it in all future code for all classes. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
