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.close()
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
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
