我并不认为DI/IoC在Python中很少见。然而，不常见的是DI/IoC框架/容器。

想想看:DI容器做什么?它允许你

将独立的组件连接成一个完整的应用程序…… ．.． 在运行时。

我们为“连接在一起”和“在运行时”命名:

脚本 动态

因此，DI容器只是动态脚本语言的解释器。实际上，让我换一种说法:典型的Java/。NET DI容器只是一个蹩脚的解释器，适用于一种非常糟糕的动态脚本语言，语法非常难看，有时是基于xml的。

当您使用Python编程时，为什么要使用一种丑陋、糟糕的脚本语言，而不是拥有一种漂亮、出色的脚本语言呢?实际上，这是一个更普遍的问题:当您使用几乎任何语言进行编程时，当您可以使用Jython和IronPython时，为什么还要使用一种丑陋、糟糕的脚本语言呢?

因此，概括一下:DI/IoC的实践在Python中和在Java中一样重要，原因完全相同。然而，DI/IoC的实现是内置在语言中，并且通常是轻量级的，以至于完全消失了。

(Here's a brief aside for an analogy: in assembly, a subroutine call is a pretty major deal - you have to save your local variables and registers to memory, save your return address somewhere, change the instruction pointer to the subroutine you are calling, arrange for it to somehow jump back into your subroutine when it is finished, put the arguments somewhere where the callee can find them, and so on. IOW: in assembly, "subroutine call" is a Design Pattern, and before there were languages like Fortran which had subroutine calls built in, people were building their own "subroutine frameworks". Would you say that subroutine calls are "uncommon" in Python, just because you don't use subroutine frameworks?)

顺便说一句:关于如何将DI引入逻辑结论的例子，可以看看Gilad Bracha的Newspeak编程语言和他关于这个主题的文章:

被认为有害的构造物 注射 禁止进口(续)

我支持“Jörg W Mittag”的回答:“DI/IoC的Python实现是如此的轻量级，以至于它完全消失了”。

为了支持这一说法，看看Martin Fowler从Java移植到Python的著名示例:Python:Design_Patterns:Inversion_of_Control

从上面的链接中可以看到，Python中的“Container”可以用8行代码编写:

class Container:
    def __init__(self, system_data):
        for component_name, component_class, component_args in system_data:
            if type(component_class) == types.ClassType:
                args = [self.__dict__[arg] for arg in component_args]
                self.__dict__[component_name] = component_class(*args)
            else:
                self.__dict__[component_name] = component_class

IoC和DI在成熟的Python代码中非常常见。由于鸭子类型，您不需要框架来实现依赖注入。

最好的例子是如何使用settings.py设置Django应用程序:

# settings.py
CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': REDIS_URL + '/1',
    },
    'local': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
        'LOCATION': 'snowflake',
    }
}

Django Rest Framework充分利用了DI:

class FooView(APIView):
    # The "injected" dependencies:
    permission_classes = (IsAuthenticated, )
    throttle_classes = (ScopedRateThrottle, )
    parser_classes = (parsers.FormParser, parsers.JSONParser, parsers.MultiPartParser)
    renderer_classes = (renderers.JSONRenderer,)

    def get(self, request, *args, **kwargs):
        pass

    def post(self, request, *args, **kwargs):
        pass

让我提醒一下(来源):

“依赖注入”是一个5美分概念的25美元术语。[…依赖注入意味着给一个对象它的实例变量。[…]。

部分原因是模块系统在Python中的工作方式。你可以免费获得一种“单例”，只需从模块中导入它。在模块中定义一个对象的实际实例，然后任何客户端代码都可以导入它，并实际获得一个工作的、完全构造/填充的对象。

这与Java相反，在Java中不导入对象的实际实例。这意味着你总是必须自己实例化它们(或使用某种IoC/DI风格的方法)。您可以通过使用静态工厂方法(或实际的工厂类)来减轻必须自己实例化所有东西的麻烦，但这样您仍然会产生每次实际创建新方法的资源开销。

你可以手动使用Python进行依赖注入，但手动方法有其缺点:

大量的样板代码来进行连接。你可以使用Python的动态特性来进行注入，但这样你就失去了IDE的支持(例如，PyCharm中的Ctrl+Space)，并且你会使代码更难理解和调试 没有标准:每个程序员都有自己解决相同问题的方法，这导致了重新发明轮子，理解彼此的代码很快就会成为一种痛苦。依赖注入库为插件提供了简单的框架

要做到这一切，我们需要一个依赖注入框架，例如这个https://python-dependency-injector.ets-labs.org/index.html似乎是Python最成熟的依赖注入框架。

对于较小的应用程序，DI容器是不必要的，对于任何有几百行代码或更多的东西，DI容器是必须的，以保持你的代码可维护性。

我同意@Jorg的观点，在Python中DI/IoC是可能的，更简单，甚至更漂亮。缺少的是支持它的框架，但也有一些例外。举几个我想到的例子:

Django注释允许您将自己的Comment类与自定义逻辑和表单连接起来。(更多信息) Django允许你使用一个自定义Profile对象来附加到你的User模型。这不是完全的IoC，但却是一个很好的方法。就我个人而言，我希望像注释框架那样取代hole User模型。(更多信息)