[Python-Dev] Garbage collecting closures

[Tim Peters]

[Paul Prescod]
> ...
> But I'm not sure where I would have learned to do so. The documentation
> for __del__ is out of date.
>
>   * http://www.python.org/doc/2.3a2/ref/customization.html
>
> The documentation lists a variety of reasons that __del__ might not get
> called (it doesn't claim to be exhaustive but it does list some cases
> that I consider pretty obscure). It doesn't list nested recursive
> functions.

__del__ isn't relevant to your test case, though:  if the cycles in question
contained any object with a __del__ method, gc would never have reclaimed
them (and gc.collect() would have had no effect on them either, other than
to move the trash cycles into gc.garbage).

You had __del__-free cycles, and then there is indeed no way to predict when
they'll get reclaimed.  I think that's just life; you wouldn't be any better
off in Java or Scheme or anything else.

It's always been difficult to guess when the implementation of a thing may
involve a cycle under the covers, and closures, generators and new-style
classes have created many new opportunities for cycles to appear.  I don't
expect users to know when they're going to happen!  I can't keep them all
straight myself.  I try to write code that doesn't care, though (avoid
__del__ methods; avoid "hiding" critical resources in side effects of what
look like simple expressions; arrange for subsystems that can be explicitly
told to release critical resources).  Ain't always easy.