我不相信以前的答案在这里。
首先请注意，给出的示例 阻止__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。
602392714
清零编程群