[za3faran]

Nothing to do with the nature of the language, but with the nature of the program.

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.

[1] https://github.com/ets-labs/python-dependency-injector

[bb88]

That DI library is not pythonic at all.

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

             [...]

Then to test:

    def test_my_class(): 
        mocked_dep1 = MagicMock()
        my_class = MyClass(my_dep1=mocked_dep1)
        [...]

[za3faran]

And if you want to configure the scope of `my_dep1` (singleton, transient, etc.)? What about nested dependencies? etc.

[bb88]

Why do I care about any of that while writing python? Those seem like artifacts of a Java based DI system.

[za3faran]

It's a reality of any non-trivial program, regardless of the language.

[bb88]

No. Some languages don't require you to play cat and mouse games to get around artificial limitations put there by the language designers.

There was a talk at PyCon a while back about that patterns commonly used in Java were non-existent in Python.