Haven't used Python in several years, but I would say that it has more to do with it being a dynamically typed language than anything else. For a simple example, in Java, if I wanted to test that something wrote to standard out appropriately I could use DI and pass in any PrintStream to capture the text being written and verify it. When I'm working in Ruby, however, I can dynamically replace the 'puts' method on STDOUT to do the verify, leaving DI completely out of the picture. If the only reason I'm creating an abstraction is to test the class that's using it (think File system operations or the clock in Java) then DI/IoC creates unnecessary complexity in the solution.

我认为由于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()

Haven't used Python in several years, but I would say that it has more to do with it being a dynamically typed language than anything else. For a simple example, in Java, if I wanted to test that something wrote to standard out appropriately I could use DI and pass in any PrintStream to capture the text being written and verify it. When I'm working in Ruby, however, I can dynamically replace the 'puts' method on STDOUT to do the verify, leaving DI completely out of the picture. If the only reason I'm creating an abstraction is to test the class that's using it (think File system operations or the clock in Java) then DI/IoC creates unnecessary complexity in the solution.

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

实际上，使用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中动态计算简单的布尔逻辑。