--- Jp Calderone <exarkun@divmod.com> wrote:

On Wed, 25 May 2005 06:12:16 -0700 (PDT), Joachim Boomberschloss <boomberschloss@yahoo.com> wrote:

...

--- Jp Calderone <exarkun@divmod.com> wrote:

...

[snip]

Rescuing an object from garbage collection is

easier

...

...

than you may expect:

exarkun@boson:~$ python Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

...

...

...

L = [] class Foo: ... def __del__(self): ... L.append(self) ... f = Foo() del f L [<__main__.Foo instance at 0xb7dff34c>]

Of course, for it to ever be collected, you'll need to take it out of that list.

Hmmm. Good to know. I thought this sort of thing was considered illegal in Python. This resolves deferring the destruction, but not the problem with reference cycles. Is there any way to do it without __del__?

The garbage collector goes to great lengths to make sure it works :)

Well, here's an example of how you'd use weakrefs. It may or may not apply to your case:

exarkun@boson:~$ python Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

...

...

...

import weakref def cleanup(handle): ... print 'Cleaned up', handle ... class Foo: ... def __init__(self, x, y, z): ... self.x, self.y, self.z = x, y, z ... self._cleanup = weakref.ref( ... self, lambda deadref: cleanup(x)) ... f = Foo('hello', 'world', 42) del f Cleaned up hello

The main point here is the isolation of the objects needed for actual cleanup from the object which may participate in a cycle. In this way, it is similar to moving the __del__ implementation onto a separate class.

Since the cleanup callback does not have access to the instance, it is somewhat more limited. For example, if the `x' attribute of a Foo instance is ever changed, the callback will still be invoked with the original value.

Got it. Well, indeed, this is not exactly what I need because of the limitation you mentioned, but I think I found a solution: to have a global object that points to all instances of Cleanuppable, and a LoopingCall that checks every minute or so whether this global object is the only referrer to each Cleanuppable instance, in which case it activates the __cleanup__ method of the Cleanuppable, and waits for the procedure to complete, then deletes the instance. This is somewhat unelegant (because of the arbitrariness of the LoopingCall as opposed to being dependent on the garbage collection process), but I think it should be completely satisfactory functionality-wise. This brings me back to the question of attractiveness, which makes me suspect that I am missing some point. What I thought was that it would be very convenient to be able to specify once, using a simple Twisted-style idiom, what should happen with an object when it is no longer needed, which, because of the way Twisted works, should be given a chance to execute before the reactor shuts down, but similarly when the object simply dies out normally (i.e. the point here is being able to use deferred to specify a non-instantaneous cleanup procedure). An example of this would be an object that interacts with a remote server that should notify the server before retiring from the interaction. I think the method I proposed including the missing element I described above handles this nicely. I'm not sure what you meant by explicit cleanup. Joe. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com