Introduction and Question
I understand what the advantages of dependency injection, e.g. constructor injection or setter injection and that it is one way of doing inversion of control. I also understand that service locators are another way of doing inversion of control - but one that should be avoided. I am following the terminology of Martin Fowler.
Dependency injection as a principle can easily done by simply defining an interface having (possibly multiple) implementations for that interface and giving one instance, which adheres to the interface to as an argument to another class/objects's method (e.g. a constructor or a setter or a different method).
I do not see why I should use a dependency injection framework (DIF). What are the advantages (and disadvantages) of using a dependency injection framework, which is no service locator framework?
I read that some framework allow things to be "registered" - but that sounds awfully close to a framework that implements the service locator pattern, not dependency injection. What's up with that? After reading the answers to Why are Service Locator frameworks often called Dependency Injection Containers?, it seems to me that - in fact - DIFs are service locator frameworks and the only part of "dependency injection" is the registration of the services into the framework. Are dependency injection frameworks secretly implementing the service locator pattern after all? One answer says that there is indeed too little benefit of a DIF if it is not a service locator, that is why such a framework does not exist.
More Background (if not important, please ignore it): I am mostly programming in Python. However, I am mostly interested in the general principle.