在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中没有被广泛使用。
当前回答
看看FastAPI，它内置了依赖注入。例如:
from fastapi import Depends, FastAPI
async def get_db():
db = DBSession()
try:
yield db
except Exception:
db.rollback()
raise
finally:
db.close()
app = FastAPI()
@app.get("/items")
def get_items(db=Depends(get_db)):
return db.get_items()
其他回答
实际上，使用DI编写足够干净和紧凑的代码是相当容易的(我想知道，它会/保持python化吗，但无论如何:))，例如，我实际上更喜欢这种编码方式:
def polite(name_str):
return "dear " + name_str
def rude(name_str):
return name_str + ", you, moron"
def greet(name_str, call=polite):
print "Hello, " + call(name_str) + "!"
_
>>greet("Peter")
Hello, dear Peter!
>>greet("Jack", rude)
Hello, Jack, you, moron!
是的，这可以被看作是参数化函数/类的一种简单形式，但它确实起作用了。所以，也许Python默认包含的电池在这里也足够了。
另外，我还发布了一个更大的例子，说明了这种简单的方法在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应用程序中，您不需要它，即使您需要它，许多讨厌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真正有价值的情况的数量甚至更有限。
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的动态特性，人们并不经常看到对另一个动态框架的需求。当一个类继承了new-style 'object'时，你可以动态地创建一个新变量(https://wiki.python.org/moin/NewClassVsClassicClass)。
即。 在普通python中:
#application.py
class Application(object):
def __init__(self):
pass
#main.py
Application.postgres_connection = PostgresConnection()
#other.py
postgres_connection = Application.postgres_connection
db_data = postgres_connection.fetchone()
不过，看看https://github.com/noodleflake/pyioc，这可能就是你要找的。
即pyioc
from libs.service_locator import ServiceLocator
#main.py
ServiceLocator.register(PostgresConnection)
#other.py
postgres_connection = ServiceLocator.resolve(PostgresConnection)
db_data = postgres_connection.fetchone()
