super and mix-in class: how exactly is the search order altered?
Veek. M
vek.m1234 at gmail.com
Sun Jul 3 10:52:44 EDT 2016
dieter wrote:
> "Veek. M" <vek.m1234 at 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).
More information about the Python-list
mailing list