In InjectableModel's initialization, initial_injections are collected in the order of the base classes.
That means that injections from the base class override injections from inheriting classes. That's the opposite order of python attribute resolution.
So, you can get into a situation where instancefoo comes from the inheriting class but instance.injector.get_instance('foo') comes from the base class.
The ordering also affects the results of injector.filter_instantiate. In particular this means that base class customizations run after inheriting class customizations
It's a little more complicated but the ordering is still inconsistent with python.
Fix the ordering breaking the API, so that customizations from classes further to the right on the MRO run before customizations from classes left on the MRO.
This will also make injector lookup give consistent results with attribute lookup.
In InjectableModel's initialization, initial_injections are collected in the order of the base classes. That means that injections from the base class override injections from inheriting classes. That's the opposite order of python attribute resolution. So, you can get into a situation where
instancefoocomes from the inheriting class butinstance.injector.get_instance('foo')comes from the base class.The ordering also affects the results of
injector.filter_instantiate. In particular this means that base class customizations run after inheriting class customizations It's a little more complicated but the ordering is still inconsistent with python. Fix the ordering breaking the API, so that customizations from classes further to the right on the MRO run before customizations from classes left on the MRO. This will also make injector lookup give consistent results with attribute lookup.