Python中是否有指向依赖项注入容器的点？

一直在摆弄python，像往常一样，它把我僵化的静态类型的面向对象世界弄得一团糟。Python支持duck类型，没有基于接口编程的可用概念（如在C#interfaces中），并且允许全局变量。有了这些优点，依赖注入容器是否真的有意义，或者Python运行时是否成为容器

我理解在静态类型的OO语言（如Java和C）中使用这些容器的意义，但是在python的疯狂世界中，这样的东西应该放在哪里呢（我喜欢它）

我一直怀疑依赖注入作为一种设计模式是一种异味，它是由一切事物产生的，必须是一个类“纳粹思维”，即c#和Java，我是正确的还是缺少什么

到目前为止，我认为只要使用Globals就可以涵盖工厂、单例、多实例对象。我也怀疑方面的东西也被涵盖了，尽管我还在思考这个问题

Duck类型是目前让我着迷的东西，所以我习惯于定义接口，然后基于这些接口创建类，让静态的东西掩盖我的愚蠢，我觉得没有静态类型，容器就有点无用

编辑

我想在使用python时，我不会使用依赖注入框架/容器。真的没有任何意义。在考虑和阅读了到目前为止的回应之后，论点清楚地表明，如果没有静态类型定义，所做的承诺是如此的松散，为什么还要麻烦呢。Duck类型就是这样，唯一的承诺就是通过文档来实现。只要引用通过符号参数进入类方法/函数，而不是通过编程环境的以太进入，那么我认为我是安全的

但令人震惊的是，我不能像在Java和C#中那样，通过过度的设计实践将我的意愿强加给他人。我在乎……不：）

结论 （以下是原始帖子中最相关的部分。我承认，我有点诗意化了，所以我觉得我应该把最重要的句子放在它们自己的部分中。也就是说，我觉得诗意化的部分很重要，所以我没有删除它。）

依赖注入仍然在使用。始终需要对象与已经实例化的对象通信。将需要“父”对象（或容器，或其他）来设置其“子”的状态。这些需要通过某种方法传递，或者通过某种赋值进行设置，但在抽象意义上，这是一样的

原来的答案是： 类型系统 在许多方面，Python是我遇到的第二种数学上最纯粹的语言——它只遵循Scheme（尽管我从未使用过Haskell，但我也知道这一点）

Python本机支持闭包，它具有连续性（屈服语法）、多重继承和循环理解语法，这在很大程度上是无与伦比的。所有这些都使它更接近阿隆佐·丘奇在《兰姆达微积分》（一本麦卡锡在Lisp背后的原创思想）中的原始愿景。Python3通过对集合的理解使它变得更加纯净（这让我的心在想到它们的内在美时怦怦直跳）

一直以来，人们都认为Python变量中存储的数据与数学中的对应数据有更多的共同点，因此对象的接口可以简化为“描述对象的形容词或形容词集”。基本上，对象的接口完全包含在其

\uuuu dict\uuuu

中，并以

dir

显示

综上所述，它确实开始让人怀疑“传统”看待事物的方式（“传统”加引号，因为Python和Java一样古老）是否真的能在这样一种语言中工作。当Python中的参数列表对它们有OOP的感觉时（kwargs，有人吗？），它真的会把世界颠倒过来

依赖注入仍然在使用。始终需要对象与已经实例化的对象通信。将需要“父”对象（或容器，或其他）来设置其“子”的状态。这些需要通过某种方法传递，或者通过某种赋值进行设置，但在抽象意义上，这是一样的。但是有一种隐含的信任，即传递对象的

\uuuu dict\uuu

的内容将包含适当的描述。正因为如此，它变得更少，“一旦我实例化了这个对象，我将赋予它生命所需的东西，”更重要的是，“嗯，是的，一个对象需要一个状态，所以我给它一个。”

这暴露了静态类型的一个隐藏方面。为了使某个期望

IFoo

的东西起作用，它必须完全了解

IFoo

的含义，即使它永远不需要90%的定义。同时，duck类型使依赖对象只知道属性X、Y和Z在运行时应该存在

全球的 至于全球的。除非你别无选择，否则要避开它们。如果单例允许您在值更改时进行日志记录，那么最好使用单例。这不是真实的全球

编程有一条规则，你的界面越暴露越复杂，维护起来就越困难。如果在全局变量中放置了某些内容，则该模块中的任何内容，以及ANY模块中的任何内容都可以修改该值。代码几乎可以变得不确定。我向你保证，悲伤随之而来

没有基于接口编程的可用概念（如C#接口）

只是因为编译器无法检查你是否是我们

def _singleton(cls):
  instance = cls()
  result = lambda: instance
  result.__doc__ = cls.__doc__
  return result

@_singleton
class example(object): pass