[Python-ideas] breaking cycles that include __del__

[Daniel Stutzbach]

On Sat, Oct 17, 2009 at 9:34 AM, Daniel Stutzbach <
daniel at stutzbachenterprises.com> wrote:

> I propose the following simple solution.  When the garbage collector is
> about to add an object to gc.garbage, it checks to see if the object has a
> __clear__ method.  If so, the garbage collector calls it, giving the object
> an opportunity to safely break any cycles it may be in.  If it breaks the
> cycles, great!  The object can now safely be collected and __del__ will
> eventually be called.  If not, then the object gets added to gc.garbage
> after all and no harm is done.
>

I should add that my personal use-case runs something like this.

Obviously, most uses of __del__ revolve around object with with special
resources that need to be freed "by hand" (such as a resource allocated via
ctypes).  To guarantee the timely freeing of resources, it's always better
to close the object by hand with a .close() method or using a context
manager.  That works great, except there's often no easy way to test a
program to verifying that .close is always called when appropriate.

There's a simple recipe to make sure that .close() was called on an object,
by using __del__ to make sure the object was closed "by hand":

class Widget:
  closed = False

  def close(self):
    if self.closed: return
    self.closed = True
    # Free various resources from ctypes, etc.

  def __del__(self):
    log_an_error('%s not closed properly' % repr(self))
    self.close()

Unfortunately, if the object ends up in a cycle, then the recipe can't do
its job because __del__ will never be called.

I think I'll experiment by having my program periodically check gc.garbage
and call any __clear__ methods it finds.  For that matter, I may just call
any __del__ methods it finds and see what happens.  If the order of calls to
__del__ matters, I'll try it as a bug in my __del__ methods.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20091019/aaec4258/attachment.html>