我正在阅读代码。 在其中定义了__del__方法的类。 我发现此方法用于销毁类的实例。 但是，我找不到使用此方法的地方。 其主要原因是我不知道如何使用此方法，可能不是这样：obj1.del()。 因此，我的问题是如何调用__del__方法？

__del__是终结器。当删除对象的所有引用之后的某个时刻发生垃圾回收时，调用该方法。

在简单的情况下，这可能是在您说del x之后，或者，如果x是局部变量，则在函数结束之后。特别是，除非有循环引用，否则CPython(标准Python实现)将立即进行垃圾回收。

但是，这是CPython的实现细节。 Python垃圾回收的唯一必需属性是，它在所有引用都被删除之后发生，因此这可能没有必要在此之后立即发生，也可能根本不发生。

此外，由于多种原因，变量可以长期存在，例如传播性异常或模块自省可以使变量引用计数大于0。而且，变量可以是引用循环的一部分—启用垃圾回收的CPython大部分(但不是全部)中断此类循环，甚至只是周期性地中断。

由于您不能保证它会被执行，因此永远不要将需要运行的代码放入__del__()中-相反，此代码属于try块的finally子句或声明。但是，__del__存在有效的用例：例如如果对象x引用Y并且还在全局cache(cache['X -> Y'] = Y)中保留Y引用的副本，那么X.__del__也删除缓存条目将是礼貌的。

如果您知道析构函数提供了(违反上述准则)必需的清除操作，则您可能希望直接调用它，因为它在方法上没有什么特别之处：x.__del__()。显然，仅当您知道不介意被两次调用时，才应该这样做。或者，作为最后的选择，您可以使用重新定义此方法

type(x).__del__ = my_safe_cleanup_method

您说CPython的将对象的引用计数减少为零后立即删除对象的功能是"实现细节"。我不相信。您能否提供备份该声明的链接？ (我的意思是，加粗字体本身很令人信服，但链接紧随其后... :-)

CPython实现细节：CPython当前使用引用计数方案，该方案具有(可选的)延迟检测循环链接的垃圾，...其他实现的行为有所不同，CPython可能会发生变化。 (docs.python.org/2/reference/datamodel.html)

在这种情况下，__exit__是什么？它是在__del__之后还是之前，还是一起运行？

您还可以使用类变量来判断其是否已经调用过__del__，因此您不必担心第二次调用。

程序终止时是否包括"可能根本不会发生"？

@AndyHayden：__del__方法即使在程序终止时也可能无法运行，即使它们确实在终止时运行，编写一个即使在解释器忙于自毁时也能正常工作的__del__方法却需要比许多方法更仔细的编码程序员申请。 (CPython清理通常使__del__方法在解释器关闭时运行，但是在某些情况下它不够用。守护进程线程，C级全局变量以及在另一个__del__中创建的带有__del__的对象都可以导致< x1>方法未运行。)

@ilyan。 python官方文档解释说，出于某些我不知道的原因，不应将__del__方法称为析构函数。您仍然认为将其称为析构函数是正确的吗？

我写下了另一个问题的答案，尽管这是一个更准确的问题。

构造函数和析构函数如何工作？

这是一个有点自以为是的答案。

不要使用__del__。这不是C ++或为析构函数构建的语言。 __del__方法确实应该在Python 3.x中消失，尽管我确信有人会发现一个有意义的用例。如果需要使用__del__，请注意每个http://docs.python.org/reference/datamodel.html的基本限制：

当垃圾回收器恰巧正在收集对象时，而不是在丢失对对象的最后一个引用时，而不是在执行del object时，会调用__del__。

__del__负责调用超类中的任何__del__，尽管尚不清楚这是按方法解析顺序(MRO)还是仅调用每个超类。

拥有__del__意味着垃圾收集器放弃了检测和清除任何循环链接的操作，例如丢失对链接列表的最后一个引用。您可以获取gc.garbage中忽略的对象的列表。您有时可以使用弱引用来完全避免循环。时不时会对此进行辩论：请参阅http://mail.python.org/pipermail/python-ideas/2009-October/006194.html。

__del__函数可以作弊，保存对对象的引用并停止垃圾回收。

在__del__中显式引发的异常将被忽略。

__del__对__new__的补充远远大于__init__。这变得令人困惑。有关说明和注意事项，请参见http://www.algorithm.co.il/blogs/programming/python-gotchas-1-del-is-not-the-opposite-of-init/。

__del__不是Python中的"可爱"子级。您会注意到sys.exit()文档没有指定是否在退出之前收集垃圾，并且存在很多奇怪的问题。在全局变量上调用__del__会引起奇怪的排序问题，例如http://bugs.python.org/issue5099。即使__init__失败，也应该调用__del__吗？有关长线程的信息，请参见http://mail.python.org/pipermail/python-dev/2000-March/thread.html#2423。

但另一方面：

__del__表示您不会忘记调用close语句。有关pro __del__观点，请参见http://eli.thegreenplace.net/2009/06/12/safely-using-destructors-in-python/。这通常与释放ctype或其他一些特殊资源有关。

我的个人原因是不喜欢__del__函数。

每当有人提出__del__时，它就会演变成三十个混乱的信息。

它在Python的Zen中打破了这些项目：

简单胜于复杂。

特殊情况还不足以打破规则。

错误绝不能默默传递。

面对模棱两可的想法，拒绝猜测的诱惑。

应该只有一种，最好只有一种明显的方式来做到这一点。

如果实现难以解释，那是个坏主意。

因此，找到不使用__del__的原因。

即使问题不完全是：为什么我们不应该使用__del__，而是如何调用__del__，您的回答却很有趣。

谢谢。有时最好的主意是避免可怕的主意。

在其他新闻中，我忘了提及PyPy(运行时间更长的应用程序的更快的解释器)将在del上中断。

感谢@Gloin更新断开的链接！

@CharlesMerriam谢谢您的回答！

您已经提到"在垃圾回收器碰巧正在收集对象时，而不是在丢失对对象的最后引用时，就会调用del"。但是，文档明确指出："注意：del x不会直接调用x .__ del __()，前者会将x的引用计数减一，而后者仅在x的引用计数达到零时才调用"。因此，当您丢失对该对象的最后一个引用时，总是会调用del。

它比我害怕的多一些。不丢失最后一个参考有很多原因，并且许多原因都是短暂的，这使得推理和调试变得困难。而且实现上有差异，并且有很多困难，还有..和...以及...尝试识别贪婪的臭虫兽，并用毛巾来避免它。

del负责调用超类中的任何del，尽管尚不清楚这是按方法解析顺序(MRO)还是仅调用每个超类。：可能它需要调用super()以及是否所有基类都执行同样，整个MRO被覆盖。

一旦编写了del操作，就将自动将消息的自动传输切换为超类。这意味着您有责任确定MRO，然后进行特殊操作的磨削。这是手动或驾驶杆。

__del__方法，当对象被垃圾回收时将被调用。请注意，不一定要调用它。以下代码本身不一定会这样做：

del obj

原因是del只是将引用计数减一。如果其他对象对该对象有引用，则不会调用__del__。

但是，有一些使用__del__的警告。通常，它们通常不是很有用。在我看来，这更像是您要使用close方法或with语句。

请参阅__del__方法上的python文档。

需要注意的另一件事：__del__方法如果使用过多，则可以禁止垃圾回收。特别是，使用__del__方法具有多个对象的循环引用将不会收集垃圾。这是因为垃圾收集器不知道首先调用哪个。有关更多信息，请参见gc模块上的文档。

当最终销毁对象时，将调用__del__方法(请注意拼写！)。从技术上讲(在cPython中)，即不再有对您对象的引用，即对象超出范围。

如果要删除对象并因此调用__del__方法，请使用

del obj1

它将删除该对象(假设没有其他引用)。

我建议你写一个这样的小班

class T:

def __del__(self):

print"deleted"

并在python解释器中进行调查，例如

>>> a = T()

>>> del a

deleted

>>> a = T()

>>> b = a

>>> del b

>>> del a

deleted

>>> def fn():

...     a = T()

...     print"exiting fn"

...

>>> fn()

exiting fn

deleted

>>>

请注意，关于何时删除对象和调用__del__的确切时间，jython和ironpython具有不同的规则。尽管由于__del__以及对象及其环境在被调用时可能处于未知状态这一事实，但这并不是使用__del__的好习惯。也不能绝对保证将调用__del__-解释器可以以各种方式退出而不删除所有对象。

与stackoverflow.com/a/2452895/611007和stackoverflow.com/a/1481512/611007相比，use del obj1似乎是个坏主意。

如前所述，__del__功能有些不可靠。在可能有用的情况下，请考虑使用__enter__和__exit__方法。这将产生类似于用于访问文件的with open() as f: pass语法的行为。进入with的作用域时会自动调用__enter__，而退出它时会自动调用__exit__。有关更多详细信息，请参见此问题。