<p>这是一个有点自以为是的答案。</p>
<p>不要使用<code>__del__</code>。这不是C++或为析构函数构建的语言。<code>__del__</code>方法确实应该在Python 3.x中消失,不过我相信有人会找到一个有意义的用例。如果需要使用<code>__del __</code>,请注意每个<a href="http://docs.python.org/reference/datamodel.html" rel="noreferrer">http://docs.python.org/reference/datamodel.html</a>的基本限制:</p>
<ul>
<li><code>__del__</code>是在垃圾收集器碰巧在收集对象时调用的,而不是在您丢失对对象的最后一个引用时调用,也不是在您执行<code>del object</code>时调用。</li>
<li><code>__del__</code>负责调用超类中的任何<code>__del__</code>,尽管它不是
如果这是方法解析顺序(MRO)或只是调用每个超类,则清除此项。</li>
<li>拥有<code>__del__</code>意味着垃圾收集器放弃检测和清理任何循环链接,例如丢失对链接列表的最后一个引用。可以从<code>gc.garbage</code>中获取忽略的对象列表。有时可以使用弱引用来完全避免循环。这一点时不时会引起争论:参见<a href="http://mail.python.org/pipermail/python-ideas/2009-October/006194.html" rel="noreferrer">http://mail.python.org/pipermail/python-ideas/2009-October/006194.html</a>。</li>
<li><code>__del__</code>函数可以欺骗、保存对对象的引用并停止垃圾收集。</li>
<li>忽略在<code>__del__</code>中显式引发的异常。</li>
<li><code>__del__</code>对<code>__new__</code>的补充远远超过<code>__init__</code>。这会让人困惑。请参阅<a href="http://www.algorithm.co.il/blogs/index.php/programming/python/python-gotchas-1-__del__-is-not-the-opposite-of-__init__/" rel="noreferrer">http://www.algorithm.co.il/blogs/index.php/programming/python/python-gotchas-1-<strong>del</strong>-is-not-the-opposite-of-<strong>init</strong>/</a>以获取解释和问题。</li>
<li><code>__del__</code>在Python中不是一个“受欢迎”的孩子。您会注意到sys.exit()文档没有指定在退出之前是否收集垃圾,并且有很多奇怪的问题。在全局变量上调用<code>__del__</code>会导致奇怪的排序问题,例如<a href="http://bugs.python.org/issue5099" rel="noreferrer">http://bugs.python.org/issue5099</a>。即使<code>__init__</code>失败,也应该调用<code>__del__</code>?有关长线程,请参见<a href="http://mail.python.org/pipermail/python-dev/2000-March/thread.html#2423" rel="noreferrer">http://mail.python.org/pipermail/python-dev/2000-March/thread.html#2423</a>。</li>
</ul>
<p>但另一方面:</p>
<ul>
<li><code>__del__</code>表示不要忘记调用close语句。有关pro<code>__del__</code>视图,请参见<a href="http://eli.thegreenplace.net/2009/06/12/safely-using-destructors-in-python/" rel="noreferrer">http://eli.thegreenplace.net/2009/06/12/safely-using-destructors-in-python/</a>。这通常是为了释放ctypes或其他一些特殊资源。</li>
</ul>
<p>以及我不喜欢<code>__del__</code>函数的个人原因。</p>
<ul>
<li>每当有人提起<code>__del__</code>时,它就演变成三十条混乱的信息。</li>
<li>它打破了Python禅中的这些项目:
<ul>
<li>复杂胜于复杂。</li>
<li>特殊情况不足以打破规则。</li>
<li>错误不应该悄无声息地过去。</li>
<li>面对模棱两可,拒绝猜测的诱惑。</li>
<li>应该有一个——最好只有一个——显而易见的方法。</li>
<li>如果实现很难解释,那是个坏主意。</li>
</ul></li>
</ul>
<p>所以,找到一个不使用<code>__del__</code>的理由。</p>