我不相信以前的答案在这里。
首先请注意，给出的示例 不会 阻止
__del__在退出过程中调用方法。实际上，当前的CPython 将
调用
__del__给定的方法，在Python 2.7中两次，在Python 3.4中一次。因此，这不能成为显示为什么不做出保证的“杀手example”。
我认为文档中的声明并非出于设计原则，即调用析构函数将是不好的。尤其重要的是，似乎在CPython
3.4及更高版本中，它们总是像您期望的那样被调用，并且此警告似乎没有意义。
相反，我认为该语句只是反映了一个事实，即CPython实现有时并未在退出时调用所有析构函数（大概是出于易于实现的原因）。
情况似乎是CPython 3.4和3.5确实总是在解释器出口调用所有析构函数。
相比之下，CPython
2.7并不总是这样做。当然，
__del__在具有循环引用的对象上通常不会调用方法，因为如果这些对象具有
__del__方法，则无法将其删除。垃圾收集器不会收集它们。尽管在解释器退出时对象确实消失了（当然），它们没有被终结，所以
__del__从不调用它们的方法。在执行PEP
442之后，在Python 3.4中不再是这样。
但是，似乎Python 2.7也不会最终确定具有循环引用的对象，即使它们没有析构函数，即使它们仅在解释器退出期间变得不可访问也是如此。
大概这种行为是非常特殊的，很难解释，就像文档一样，最好仅通过通用免责声明来表达。
这是一个例子：
class Foo(object): def __init__(self): print("Foo init running") def __del__(self): print("Destructor Foo")class Bar(object): def __init__(self): print("Bar1 init running") self.bar = self self.foo = Foo()b = Bar()# del b随着
del b注释掉，在析构函数
Foo是不是在Python 2.7叫虽然它是在Python 3.4。
随着
del b加入，然后调用析构函数（在解释退出）在这两种情况下。
