我不相信以前的答案在这里。

首先请注意，给出的示例 不会 阻止__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加入，然后调用析构函数（在解释退出）在这两种情况下。