Weakref.ref callbacks and eliminating __del__ methods

Mike C. Fletcher mcfletch at rogers.com
Sun Jan 23 17:40:43 EST 2005

I'm looking at rewriting parts of Twisted and TwistedSNMP to eliminate 
__del__ methods (and the memory leaks they create).  Looking at the docs 
for 2.3's weakref.ref, there's no mention of whether the callbacks are 
held with a strong reference.  My experiments suggest they are not...  
i.e. I'm trying to use this pattern:

class Closer( object ):
    """Close the OIDStore (without a __del__)"""
    def __init__( self, btree ):
        """Initialise the closer object"""
        self.btree = btree
    def __call__( self, oldObject=None ):
        """Regular call via self.close or weakref deref"""
        if self.btree:
            self.btree = None
class BSDOIDStore(oidstore.OIDStore):
    def __init__( self, filename, OIDs = None ):
        """Initialise the storage with appropriate OIDs"""
        self.btree = self.open( filename )
        self.update( OIDs )
        self.close = Closer( self.btree )
        weakref.ref( self, self.close )

but the self.close reference in the instance is going away *before* the 
object is called.

So, this approach doesn't *seem* to work (the Closer doesn't get 
called), so I can gather that the callbacks don't get incref'd (or they 
get decref'd during object deletion).

I can work around it in this particular case by defining a __del__ on 
the Closer, but that just fixes this particular instance (and leaves 
just as many __del__'s hanging around).  I'm wondering if there's a 
ready recipe that can *always* replace a __del__'s operation? 

I know I heard a rumour somewhere about Uncle Timmy wanting to eliminate 
__del__ in 2.5 or thereabouts, so I gather there must be *some* way of 
handling the problem generally.  The thing is, weakref callbacks trigger 
*after* the object is deconstructed, while __del__ triggers before... 
must be something clever I'm missing.

Throw an old doggie a bone?

  Mike C. Fletcher
  Designer, VR Plumber, Coder

More information about the Python-list mailing list