[Tim]
> there's no 100% guarantee that a __del__ method will ever get called
Can anyone point me to any definitive documentation on why this is the
case? I was under the impression that __del__ would always be called:
1. for objects not in cycles and with no references
2. for objects whose o
[Tim]
>> I'll note that one fairly obvious pattern works very well for weakrefs
>> and __del__ methods (mutatis mutandis): don't put the __del__ method
>> in self, put it in a dead-simple object hanging *off* of self. Like
>> the simple:
>>
>> class BTreeCloser:
>> def __init__(self, btree):
Tim Peters wrote:
[Mike C. Fletcher]
I'm looking at rewriting parts of Twisted and TwistedSNMP to eliminate
__del__ methods (and the memory leaks they create).
A worthy goal!
Well, as of now it seems to have eliminated the last leaks in
TwistedSNMP, and that's likely going to eliminate
[me]
> why the `self.btree = None` in the last line?
[Mike]
> It's to allow the Closer object to act as a substitute for a .close()
> method on the object [...] If the user explicitly calls storage.close()
> we don't want the __del__ trying to re-close the storage later. In
> other words, its a
Richie Hindle wrote:
[Tim]
I'll note that one fairly obvious pattern works very well for weakrefs
and __del__ methods (mutatis mutandis): don't put the __del__ method
in self, put it in a dead-simple object hanging *off* of self. Like
the simple:
class BTreeCloser:
def __init__(self, btree)
[Tim]
> I'll note that one fairly obvious pattern works very well for weakrefs
> and __del__ methods (mutatis mutandis): don't put the __del__ method
> in self, put it in a dead-simple object hanging *off* of self. Like
> the simple:
>
> class BTreeCloser:
> def __init__(self, btree):
>
[Mike C. Fletcher]
> I'm looking at rewriting parts of Twisted and TwistedSNMP to eliminate
> __del__ methods (and the memory leaks they create).
A worthy goal!
> Looking at the docs for 2.3's weakref.ref, there's no mention of whether the
> callbacks are held with a strong reference.
A callback
Alex Martelli wrote:
Mike C. Fletcher <[EMAIL PROTECTED]> 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 goin
Mike C. Fletcher <[EMAIL PROTECTED]> 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 afte
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
10 matches
Mail list logo
