4

How soon after the reference count reaches zero is __del__ method called? Does the language promise that it's done right away, before any other use code can execute? Or can each implementation do what it likes, potentially delaying the call to __del__ arbitrarily long?

Please ignore the situation when the program is about to exit (I assume it means the last statement in the given block has finished, and the stack is empty). I understand that in such cases, there's no promises about __del__; it may not even be called at all.

Also, I'm aware that reference count may be non-zero due to cycles, etc. I am not concerned about that here (I'm asking a separate question about it).

max
  • 49,282
  • 56
  • 208
  • 355
  • 3
    By saying "the reference count", you are already making assumptions. – Karl Knechtel Mar 20 '12 at 23:40
  • 1
    If you consider implementing it, read the **big fat red warning** first: http://docs.python.org/reference/datamodel.html#object.__del__ – ThiefMaster Mar 20 '12 at 23:43
  • You basically never want to do anything with `__del__`: http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx – SingleNegationElimination Mar 20 '12 at 23:46
  • 1
    @KarlKnechtel: Agreed. If I rephrase it to say "after the last non-weak reference to the object disappears", does it remove unnecessary assumptions? – max Mar 21 '12 at 00:51

3 Answers3

11

Python doesn't make any guarantees about when __del__ is called, or whether it is called at all. As it is, __del__ methods are unlikely to be called if the object is part of a reference cycle, because even if the cycle as a whole is cleaned up, Python has no way to decide where to break the cycle and in what order the __del__ methods (if any) should be called. Because of __del__'s rather quirky semantics (in order to call __del__ the refcount of the object is temporarily increased, and the __del__ method can prevent destruction of the object by storing the reference somewhere else) what happens in other implementations is a bit of a crapshoot. (I don't remember the exact details in current Jython, but it has changed a few times in the past.)

That said, in CPython, if __del__ is called, it's called as soon as the reference count drops to zero (since refcounting is the only way __del__ methods are called, and the only chance CPython has of calling __del__ is when the actual refcount is changed.)

Thomas Wouters
  • 130,178
  • 23
  • 148
  • 122
  • 2
    So basically if you have to ask, don't do it. – John La Rooy Mar 20 '12 at 23:53
  • The `gc` module is there to break reference cycles. – Chris Morgan Mar 21 '12 at 00:02
  • 1
    The `gc` module can't break reference cycles that involve objects with `__del__` methods. Instead it stuffs them into `gc.garbage` and forgets about them. You can go through `gc.garbage` and break those cycles yourself, if you know how to break them, but the `gc` module won't do it for you. – Thomas Wouters Mar 21 '12 at 00:13
  • So when (if ever) should I use `__del__`, if I want to be perfectly consistent with the language intent, and not rely on any implementation details? – max Mar 21 '12 at 19:05
  • For nothing. `__del__` doesn't provide anything you can't get through more sensible means, like weakref callbacks or by relying on Python to clean up other objects. – Thomas Wouters Mar 21 '12 at 20:26
  • Note that there can be a reference cycle that keeps a reference to an object with `__del__` (but the object with `__del__` is not part of the cycle). In this case the `__del__` is indeed called when refcount reaches 0, but it's later than you might think it is. Also calling `__del__` at the interpreter exit time is messier (and might not happen at all) – fijal Mar 22 '12 at 18:44
5

About the only reason you should ever use __del__ is to help the garbage collector collect more garbage. For instance, if you are implementing something like the ctypes module that attaches shared libraries to the running process, it makes sense to unload those libraries when the last reference to it is collected, to allow its address space to be used for something else.

For managing other kinds of resources, you almost certainly don't want to have anything to do with the garbage collector. The correct tool for this is context managers. Unlike languages such as C++ or Ada where variable scope is used for RAII, python uses the with statement, along with an object that has an __enter__ and __exit__ method. Many built in python types use this exact mechanism to make sure finalization steps actually occur:

>>> x = file("foo", 'w')
>>> x.closed
False
>>> with x:
...     x.write("bar")
... 
>>> x.closed
True

This is also valuable from the point of view of the zen of python:

Explicit is better than implicit.

because it is clear that cleanup is occuring, it is explicitly written that way. This is much better than the case of cleanup happening "magically" when some hidden variable (the reference count, if one exists, and it doesn't in PyPy or IronPython or Jython) reaches some particular value, maybe.

SingleNegationElimination
  • 151,563
  • 33
  • 264
  • 304
  • 1
    Weakref callbacks are a much better way of implementing the kind of cleanup that you suggest `__del__` methods are for, because they don't prevent cleanup of cycles. The only reason `__del__` exists as it does is because it predates considerations of non-refcount Python implementations as well as weakrefs. – Thomas Wouters Mar 21 '12 at 00:34
3

Please read the CPython object.__del__ docs. This says most of what needs to be said, but is implementation specific; most other Python implementations don't use refcounting and so you shouldn't depend on it being called at such and such a time (or even being called at all) for functionality. It gets called at the time of destruction—which will vary between implementations.

Chris Morgan
  • 86,207
  • 24
  • 208
  • 215