On Wed, 21 Jul 2010 11:42:00 -0400 Jesse Noller <jnol...@gmail.com> wrote: > On Wed, Jul 21, 2010 at 11:11 AM, Tim Golden <m...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com