__del__ is used for finalization when the obj is reclaimed by GC. On refcounting implementations like CPython, this occurs as soon as the refcount goes to zero. On Jython, this may occur whenever the GC does this, possibly after a number of rounds of GC. In other words, it's not a good idea to depend on it happening at a specific time.

Testing - especially of __del__ itself - may require this to be done in a predictable fashion. In this case, you will see in the Jython unit tests this pattern:

import gc, time
gc.collect(); time.sleep(1); gc.collect()

Or worse yet, in gc.collect(); sleep(1); gc.collect(); sleep(0.1); gc.collect()

(I have no idea what the sleep time should really be here, and in this case, I don't care. Whatever works.)

Obviously this forced finalization is not suitable except for such test scenarios. Even then, to use the technical term, it's super ugly. In general, __del__ (much like Java finalizers) is rarely needed, basically around external resources - and this is when you've written that wrapper, something like subprocess or socket. Better practice is to use try/finally with whatever closing method (often "close"). Even better practice with 2.5 is to use the with-statement to manage this on your behalf.

- Jim

On Wed, Feb 11, 2009 at 10:36 AM, Noam Aigerman <> wrote:

I defined in some class

def __del__(self):
   print 'fooooooo'

though, even when i do
del X
for an object of the class above, I don't see any 'fooooooo' printed... Is there a reason? A way around it?
Thanks, Noam

Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-
Jython-users mailing list

Jim Baker