[Python-Dev] Python Language Summit EuroPython 2010

[Antoine Pitrou]

On Wed, 21 Jul 2010 11:42:00 -0400
Jesse Noller <jnoller at gmail.com> wrote:
> On Wed, Jul 21, 2010 at 11:11 AM, Tim Golden <mail at timgolden.me.uk> wrote:
> [...snip...]
> > A messy discussion turned on the question of garbage collection of module
> > objects, and the order in which finalisers are called if at all, especially
> > when reference cycles exist. Marc Andre was proposing a __cleanup__ magic
> > function
> > for Python modules, which would enable the implementer to define the order
> > in which resources are released / closed down. This is quite a subtle area
> > and raised the issue of unfinalised objects in a reference cycle whose
> > memory has been freed out from under them but which still exist. Martin
> > described
> > the Java approach where finalisers are called once and then flagged so
> > they are not called again even if their object is resurrected. This sounded
> > like a useful approach for Python but would break code which expected to
> > be able to resurrect an object during its __del__ method... which is not
> > expected to account for much code.
> >
> > Guido pointed out that no-one can be expected to hold enough of the
> > complexities
> > of this area of Python's implementation in their head, and that an
> > implementation
> > of some sort would need to be written so that the corner-cases could emerge.
> 
> FWIW; I'm currently dealing with a bug in this area w.r.t
> multiprocessing and threads and modules we have imported vanishing due
> to this issue. I'm interested in hearing more.

One common resolution is to not use a __del__ method, but instead a
weakref callback which will do the necessary cleanup of a certain set
of resources. This is of course not applicable in all situations.