0

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?

He says very clearly "not alter the source code for LoggingDict" so clearly he means that somehow, magically - the search order for super().__setitem__ in

class LoggingDict(dict):
    def __setitem__(self, key, value):
        logging.info('Settingto %r' % (key, value))
        super().__setitem__(key, value)

is being altered/influenced, but how? Could someone clarify what exactly is going on here? Far as I can make of it, the tree looks like this: super_search

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
  • Did you read the preceding paragraph? *"the important result is that `OrderedDict` was inserted after `LoggingDict` and before `dict`! This means that the `super()` call in `LoggingDict.__setitem__` now dispatches the key/value update to `OrderedDict` instead of `dict`."* The method resolution order (MRO) flattens the diagram you have drawn, as explained in the duplicate. – jonrsharpe Jul 01 '16 at 12:55
  • i did read that para - in fact it's underlined in yellow. My point is: LoggingDict has NOT been altered in any way at all - the src hasn't been changed. So LoggingDict DOES NOT inherit LoggingOD, INSTEAD it's the other-way around. So how the heck is the fact that LoggingOD deriving from LoggingDict, altering the LoggingDict.__mro__ ???? It should alter the LoggingOD.__mro__ –  Jul 01 '16 at 13:04
  • therefore any instance of LoggingOD will use the LoggingOD.__mro__ and have it's lookup sent to collections.OrderedDict –  Jul 01 '16 at 13:07
  • isn't inheritance a one way street? –  Jul 01 '16 at 13:08
  • *"LoggingDict has NOT been altered in any way"* - correct. *"LoggingDict DOES NOT inherit LoggingOD, INSTEAD it's the other-way around"* - correct, and nothing has implied otherwise. *"how the heck is the fact that LoggingOD deriving from LoggingDict, altering the LoggingDict.__mro__"* - it doesn't, as you could see by printing it before and after defining `LoggingOD`. *"It should alter the LoggingOD.__mro__"* - not "alter" so much "create", but yes. *"any instance of LoggingOD will use the LoggingOD.__mro__ and have it's lookup sent to collections.OrderedDict"* - also yes. – jonrsharpe Jul 01 '16 at 13:08
  • Note it says *"control"* the search order - not *"alter"*. The existence of `LoggingOD` doesn't change the classes it inherits from. *"isn't inheritance a one way street?"* - yes, and it's not clear how you think this is claiming otherwise. – jonrsharpe Jul 01 '16 at 13:10
  • but if that is the case, a lookup on an instance attribute of LoggingDict cannot take the path marked 1 (that's a one-way street) LoggingDict is the PARENT class of LoggingOD. Searches don't propagate down the tree –  Jul 01 '16 at 13:15
  • Please read the duplicate and take some time to absorb it. Also see https://www.python.org/download/releases/2.3/mro/. The inheritance tree is not the same as the resulting flattened MRO. – jonrsharpe Jul 01 '16 at 13:16

0 Answers0