Dependency inversion in python - why is it used? Can't see the benefit

Question

I've been trying to understand dependency inversion in python. I understand the theory that everybody quotes but I've not yet seen the code example with and without inversion that would clearly demonstrate the benefits. I've found only one highly rated answer here that shows the code I pasted below but if you scroll down I also pasted same code without abstraction and it does the same thing and it is also modular. The only benefit I see is that using abstraction prevents someone making changes to the name of the method...

I am still struggling to understand the need for dependency inversion. Looking at the code below one uses dependency inversion and the other does not. They both seem to accomplish the same purpose and are equally modular... What's going on?

class IFood:
    def bake(self): pass
    def eat(self): pass

class Bread(IFood):
    def bake(self):
        print("Bread was baked")
    def eat(self):
        print("Bread was eaten")

class Pastry(IFood):
    def bake(self):
        print("Pastry was baked")
    def eat(self):
        print("Pastry was eaten")

class Production:
    def __init__(self, food): 
        self.food = food 
    def produce(self):
        self.food.bake() 

    def consume(self):
        self.food.eat()

ProduceBread = Production(Bread())
ProducePastry = Production(Pastry())

ProducePastry.consume()

vs.

class Bread():
    def bake(self):
        print("Bread was baked")
    def eat(self):
        print("Bread was eaten")

class Pastry():
    def bake(self):
        print("Pastry was baked")
    def eat(self):
        print("Pastry was eaten")

class Production:
    def __init__(self, food):
        self.food = food

    def produce(self):
        self.food.bake()

    def consume(self):
        self.food.eat()

ProduceBread = Production(Bread())
ProducePastry = Production(Pastry())

ProducePastry.consume()

I've been playing with the code trying to spot an obvious benefit of dependency inversion in python but with no good results.

Answer 1

Both examples use dependency injection. The only difference is that IFood is a quasi-abstract base class the indicates its subclasses should define bake and eat.

The alternative would be a definition of Production similar to

class Production:
    def __init__(self, food): 
        self.food = food 
    def produce(self):
        if isinstance(food, Bread):
            print("Bread was baked")
        elif isinstance(foo, Pastry):
            print("Pastry was baked")
        else:
            print(f"I don't know how to bake {self.food}")

    def consume(self):
        if isinstance(food, Bread):
            print("Bread was eaten")
        elif isinstance(foo, Pastry):
            print("Pastry was eaten")
        else:
            print(f"I don't know how to eat {self.food}")

If another food product were created, you would need to modify the definitions of Production.produce and Production.consume into ever longer if statements. With dependency inversion, the only thing you need t do is define your new Food subclass; Production itself doesn't need to change at all.

---

A more idiomatic version of the IFood-based solution would use the abc module. Type hints are added to more explicitly demonstrate the role of IFood in Production.

from abc import ABC, abstractmethod

class Food(ABC):
    @abstractmethod
    def bake(self):
        pass

    @abstractmethod
    def eat(self):
        pass


class Bread(Food):
    def bake(self):
        print("Bread was baked")

    def eat(self):
        print("Bread was eaten")

class Pastry(Food):
    def bake(self):
        print("Pastry was baked")

    def eat(self):
        print("Pastry was eaten")


class Production:
    def __init__(self, food: Food): 
        self.food = food 

    def produce(self):
        self.food.bake() 

    def consume(self):
        self.food.eat()

bread_producer = Production(Bread())
pastry_producer = Production(Pastry())

pastry_producer.consume()

If you wanted to add a third type of food to produce, just define a new subclass of Food.

class Bacon(Food):
     def bake(self):
         print("Bacon was fried")

     def eat(self):
         print("Bacon was devoured")

bacon_producer = Production(Bacon())
bacon_producer.produce()
bacon_producer.consume()

---

An example of dependency inversion that you use frequently in Python is the str type. You can pass values of many different types to str and get back a string.

>>> str(1)
'1'
>>> str(3.14159)
'3.14159'
>>> str(int)
"<class 'int'"

str itself doesn't know how to do this, i.e., the definition of str does not look like

def str(x):
    if instanceof(x, int):
        return int_to_str(x)
    elif instanceof(x, float):
        return float_to_str(x)
    elif instanceof(x, type):
        return type_to_str(x)
    elif ...

Instead, every value that you want to turn into a str provides its own function for doing so: instead of the result given x depending on str, the behavior of str depends on x: the dependency has been inverted.

def str(x):
    return x.__str__()

Now, if you want to define a class X and have str(X()) output something other than '<X object at 0x28342827>', you just define X.__str__ instead of having to modify your Python interpreter itself to change the built-in definition of str.

>>> class X:
...    def __str__(self): return "I'm an X!"
...
>>> str(X())
"I'm an X!"

Answer 2

It is not the easiest to demonstrate DI on a small scale/toy projects. Yes of course, when your entire behaviour can fit into 20 lines, it will not do anything. The value comes, when you

A) have a larger project with multiple modules interfacing with each other, and/or B) make use of Python's Type hint system

Let's examine these:

On a larger project, DI with base classes provides a contract for what you need a class to implement. Thereby you decouple the behaviour of the implementation and the consumption. It also makes it easier to modify parts, without having to consider the consumer of the class.

Reworking your example, starting with:

class IPersistance:
    def save(self, key, data): raise NotImplementedError
    def load(self, key): raise NotImplementedError

class DiskPersistance:
    def save(self, key, data):
        print("I'm saving the data to disk")

    def load(self, key):
        print("I'm loading the data from disk")

class Service:
    def __init__(self, persitance):
        self._persistance = persistance

    def do_operation(self, some_data):
        self._persistance.save(some_key, some_data)

Now if you want to add a new type of persistance, for example a database, you know exactly what the consumer of IPersistance expects. And you can freely replace DiskPersistance in Service with DBPersistance for example.

Next, type hints:

Having the base class (interface) allows you to abstract away the question of what will this method return/expect as argument. You have had to define that ahead of time, and then understand that any implementation will have to accept and return the types as specified by the base class. And your consumer can then fully ignore any kind of implementation, and know what types it has to pass in, and what to expect as result.

Updating the above example:

class IPersistance:
    def save(self, key: int, data: str) -> None: raise NotImplementedError
    def load(self, key: int) -> str: raise NotImplementedError

class DiskPersistance:
    def save(self, key: int, data: str) -> None:
        print("I'm saving the string data to disk using the numeric id")

    def load(self, key: int) -> str:
        print("I'm loading the str data from disk")

class Service:
    def __init__(self, persitance: IPersistance):
        self._persistance = persistance

    def do_operation(self, some_data: str):
        some_key = 1
        self._persistance.save(some_key, some_data)

And as the folks in the comments have pointed out, your examples is still dependency inversion, just without the type guarantees.