I've never been a big fan of dependency injection. It solves a problem with unit testing in Java, sure, but the reality is that Java could have done some nifty things to help alleviate that as well.
I know pytest does DI with fixtures, and trying to figure out what you're pulling into a test can be difficult.
The user doesn't write DI code for Django Class Based views. E.g. the view doesn't accept a Database upon instantiation.
If you're writing a few line script, you don't need a DI container. Once your program gets large, it becomes extremely messy without one. It's no surprise projects like [1] exist.
There's nothing wrong with this at all, say:
class MyClass:
def __init__(self, my_dep1=None):
if my_dep1 is None:
self.my_dep1 = get_my_dep1() # Or potentially raise
else:
self.my_dep1 = my_dep1
[...]
def test_my_class():
mocked_dep1 = MagicMock()
my_class = MyClass(my_dep1=mocked_dep1)
[...]There was a talk at PyCon a while back about that patterns commonly used in Java were non-existent in Python.
Any complicated DI solution must have a reason for it being there and I’ve seen too many projects complicating themselves on buzzwords like DI or MSOA without really needing either that much