Weakref.ref callbacks and eliminating __del__ methods

Discussion in 'Python' started by Mike C. Fletcher, Jan 23, 2005.

  1. 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
     
    Mike C. Fletcher, Jan 23, 2005
    #1
    1. Advertising

  2. Mike C. Fletcher <> wrote:

    > weakref.ref( self, self.close )
    >
    > but the self.close reference in the instance is going away *before* the
    > object is called.


    Uh -- what's holding on to this weakref.ref instance? I guess the
    weakreference _itself_ is going away right after being created...


    Alex
     
    Alex Martelli, Jan 23, 2005
    #2
    1. Advertising

  3. Alex Martelli wrote:

    >Mike C. Fletcher <> wrote:
    >
    >
    >
    >> weakref.ref( self, self.close )
    >>
    >>but the self.close reference in the instance is going away *before* the
    >>object is called.
    >>
    >>

    >
    >Uh -- what's holding on to this weakref.ref instance? I guess the
    >weakreference _itself_ is going away right after being created...
    >
    >

    You know, you're right. I'd been thinking (not-very-clearly) that
    registering the callback would keep the reference alive until it was
    called, guess I'm too used to PyDispatcher's operation. Urgh, that's
    seriously annoying, requires storing the callback somewhere external.

    Back to __del__ I suppose.

    Thanks Alex,
    Mike


    ________________________________________________
    Mike C. Fletcher
    Designer, VR Plumber, Coder
    http://www.vrplumber.com
    http://blog.vrplumber.com
     
    Mike C. Fletcher, Jan 24, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike C. Fletcher
    Replies:
    0
    Views:
    429
    Mike C. Fletcher
    Jan 24, 2005
  2. Replies:
    0
    Views:
    357
  3. Replies:
    22
    Views:
    788
    peter koch
    Apr 30, 2008
  4. George Sakkis
    Replies:
    6
    Views:
    308
    George Sakkis
    Jun 12, 2008
  5. Justin C
    Replies:
    1
    Views:
    198
    Justin C
    Oct 7, 2013
Loading...

Share This Page