在Java中，IoC / DI是一种非常常见的实践，广泛应用于web应用程序、几乎所有可用的框架和Java EE中。另一方面，也有很多大型的Python web应用程序，但除了Zope(我听说它的编码真的很糟糕)之外，IoC在Python世界中似乎并不常见。(如果你认为我是错的，请举一些例子)。
当然，有一些流行的Java IoC框架的克隆可用于Python，例如springpython。但它们似乎都没有被实际使用。至少，我从来没有碰到过Django或sqlalchemy+<插入您最喜欢的wsgi工具箱在这里>的基于web应用程序使用类似的东西。
在我看来，IoC有合理的优势，可以很容易地取代django-default-user-model，但在Python中广泛使用接口类和IoC看起来有点奇怪，而且不»pythonic«。但是也许有人有更好的解释，为什么IoC在Python中没有被广泛使用。
当前回答
我支持“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
其他回答
你可以手动使用Python进行依赖注入，但手动方法有其缺点:
大量的样板代码来进行连接。你可以使用Python的动态特性来进行注入，但这样你就失去了IDE的支持(例如，PyCharm中的Ctrl+Space)，并且你会使代码更难理解和调试 没有标准:每个程序员都有自己解决相同问题的方法，这导致了重新发明轮子，理解彼此的代码很快就会成为一种痛苦。依赖注入库为插件提供了简单的框架
要做到这一切，我们需要一个依赖注入框架，例如这个https://python-dependency-injector.ets-labs.org/index.html似乎是Python最成熟的依赖注入框架。
对于较小的应用程序，DI容器是不必要的，对于任何有几百行代码或更多的东西，DI容器是必须的，以保持你的代码可维护性。
我的观点是，在大多数Python应用程序中，您不需要它，即使您需要它，许多讨厌Java的人(以及自认为是开发人员的无能的摆弄者)很可能认为它很糟糕，只是因为它在Java中很受欢迎。
An IoC system is actually useful when you have complex networks of objects, where each object may be a dependency for several others and, in turn, be itself a dependant on other objects. In such a case you'll want to define all these objects once and have a mechanism to put them together automatically, based on as many implicit rules as possible. If you also have configuration to be defined in a simple way by the application user/administrator, that's an additional reason to desire an IoC system that can read its components from something like a simple XML file (which would be the configuration).
典型的Python应用程序要简单得多，只有一堆脚本，没有这么复杂的体系结构。就我个人而言，我知道IoC实际上是什么(与那些在这里写下某些答案的人相反)，在我有限的Python经验中，我从来没有觉得需要它(而且我不会在任何地方都使用Spring，当它所提供的优势不足以证明它的开发开销时)。
也就是说，在Python中，IoC方法实际上是有用的，事实上，我在这里读到Django使用了它。
上述相同的推理可以应用于Java世界中的面向方面编程，不同的是，AOP真正有价值的情况的数量甚至更有限。
所有基于DI的pytest夹具(来源)
我并不认为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编程语言和他关于这个主题的文章:
被认为有害的构造物 注射 禁止进口(续)
IoC/DI是一个设计概念，但不幸的是，它经常被认为是一个适用于某些语言(或类型系统)的概念。我希望看到依赖注入容器在Python中变得更加流行。有Spring，但它是一个超级框架，似乎是Java概念的直接移植，没有太多考虑“Python方式”。
鉴于Python 3中的注释，我决定尝试一个功能齐全但简单的依赖注入容器:https://github.com/zsims/dic。它基于。net依赖注入容器的一些概念(如果你曾经在那个领域玩过，IMO是很棒的)，但与Python概念发生了变化。
