dieter wrote: > "Veek. M" <vek.m1...@gmail.com> writes: >> ... >> I'm reading this article: >> https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ >> >> He's trying to explain the purpose of a 'mix-in class' and he says >> >> We did not alter the source code for LoggingDict. Instead we >> built a >> subclass whose only logic is to compose two existing classes and >> control their search order. >> >> class LoggingOD(LoggingDict, collections.OrderedDict): >> pass >> >> My question is this: in the above article context, is he talking >> about the LoggingDict's search order that is being manipulated? Or he >> is talking about manipulating the LoggingOD search order? > > Likely, his language has been a bit sloppy. > > Likely, his setup is as follows: > > * He has an existing class ("collections.OrderDict") > which the base functionality he needs > > * He has an additional requirement (over that of > "collections.OrderDict") > -- logging modifications > > * He wants to implement his requirements (the base ones and the > the additional one) without modifying the existing class in any way > > * His idea to implement the additional requirement is to define > a derived class ("LoggingOD") and lets its modifying methods > perform the logging and then call the corresponding methods of the > base class. > > * He recognizes that this logging feature might be interesting > not only for "collections.OrderDict" but also for other > dictionary like base classes. > Therefore, instead of implementing it directly in > "LoggingOD", he implements it in the mixin class "LoggingDict". > > * Because "LoggingDict" was explicitely designed to be used > as mixin class to enhance a base class, it knows that > some methods ("__setitem__") of the base class need to be called > in its own implementation of the corresponding method. > > * The integrator (the one combining "LoggingDict" with the base > class) must ensure (by an appropriate inheritance order) > that the combining class ("LoggingOD" in the example) > calls the "LoggingDict"'s methods (which know about that of the > base class) rather than the base class's methods (which do not > know about the mixin class's methods). > > Therefore, he uses the inheritance order "LoggingDict" followed > by the base class (and not vice versa). > > > Python clearly defines in what order attributes of an object > and of the construct "super(<base>,<obj>)" are looked up. > > The essential concept is the so called "MRO" ("method resolution > order") (in fact, it is an attribute resolution order). > > In simple cases (no common base classes), the MRO of > a definition "class C(B_1, ..., B_n): ..." > is defined by a left to right lookup: i.e. first in "C", then "B_1", > then "B_2", ... > > The rules are a bit more complicated when the "B_i" have a (or more) > common base classes.
Hey Dieter, I'll need some time to read this and get back on it - hope that's okay. But yeah, I think he's explaining it badly and extremely misleading (imho). -- https://mail.python.org/mailman/listinfo/python-list
