Agreed. Java injection frameworks are opaque and accomplish what they need to with overly powerful mechanisms because of the nature of the language. You don't see that sort of nonsense in python.

Wtf, so what do you think Django is?

I'm curious to understand what dependency injection is in Django that you're referring to?

I know pytest does DI with fixtures, and trying to figure out what you're pulling into a test can be difficult.

In django you're importing a default cache, a default storage etc, and write your code to the interface. In settings.py you wire it all up. It's basically the same, for testing you would have to mock the import or provide some implementation.

technically that's not dependency injection, but a global service locator.

Yeah I agree on that here.

The user doesn't write DI code for Django Class Based views. E.g. the view doesn't accept a Database upon instantiation.

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

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)
        [...]

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

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

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

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.

If that’s the only thing it’s used for in the project, then you are most likely good with Autowired (in Sping) or something similar.

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

Sounds like you’re confusing DI with DI containers.