On Wed, Jul 21, 2010 at 16:58, Antoine Pitrou <solipsis at pitrou.net> wrote: > 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. That's an option. I just remember Tim bringing up something about that approach that didn't quite work as a complete replacement for __del__. Basically the whole setting a module's globals to None was done before gc came into the language. Now that it's there it seems that it might work to simply let gc clean up the module itself. But this brings in the question of how to order calling finalizers. It seemed the room had no specific answer other than it might just have to be near random as figuring out a reasonable order is hard. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20100722/bf1f848d/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4