> Are you talking about the __new__ method ? Or about metaclasses ?
Sorry Bruno, I should have made that a little clearer. I was talking about the
__new__ method.
Cheers mate,
Robert
--
http://mail.python.org/mailman/listinfo/python-list
Robert Rawlins a écrit :
Time to fix that, then, with some documentation
http://www.python.org/doc/>, and by working through the Python
tutorial http://www.python.org/doc/tut/>.
Thanks Ben, I'll be sure to read through these. I also read through
this http://www.geocities.com/foetsch/python/ne
> Time to fix that, then, with some documentation
> http://www.python.org/doc/>, and by working through the Python
> tutorial http://www.python.org/doc/tut/>.
Thanks Ben, I'll be sure to read through these. I also read through this
http://www.geocities.com/foetsch/python/new_style_classes.htm ear
"Robert Rawlins" <[EMAIL PROTECTED]> writes:
> This isn’t something I'd seen before (god that makes me feel stupid).
No need to feel stupid, unless you've had the opportunity to learn and
passed it by.
> I've always based my code off the odd example that's dotted around
Time to fix that, then,
> In Python 2.x, "classic" classes (which are not part of the unified
> type hierarchy) are deprecated, and exist only for backward
> compatibility with old code.
>
> You need to create "new-style" classes
> http://www.python.org/doc/newstyle/> by inheriting from some
> class that is part of the un
"Robert Rawlins" <[EMAIL PROTECTED]> writes:
> What is the benefit of extending the base 'object' class? What does that
> give me that en empty, non subclassed object doesn't?
In Python 2.x, "classic" classes (which are not part of the unified
type hierarchy) are deprecated, and exist only for ba
"Robert Rawlins" <[EMAIL PROTECTED]> wrote:
> I like this idea, I can definitely see the benefits to working with
> this concept. One things I will take this quick opportunity to ask,
> even though it's a little OT:
>
> What is the benefit of extending the base 'object' class? What does
> that giv
Hi Duncan,
> That sounds like an appropriate use for __del__: it won't matter that it
> may not be called when your app exits.
Ok, well that's good to know. :-)
> Yes, but there is an easy work-around. If you want to track destruction of
> objects of type C then don't add a __del__ method to t
"Robert Rawlins" <[EMAIL PROTECTED]> wrote:
> I've just recently (in the past week) started using the __del__ method
> to log class instance destruction so I can keep a track of when
> objects are created and destroyed, in order to help me trace and fix
> memory leaks.
That sounds like an approp
> Yes.
>
> "Objects that have __del__() methods and are part of a reference cycle
> cause the entire reference cycle to be uncollectable, including
> objects not necessarily in the cycle but reachable only from it.
> Python doesn't collect such cycles automatically bec
to guess a safe order in which to run the
__del__() methods."
The uncollectable objects are stored in gc.garbage and will not be
freed until their reference cycles are broken and they are removed
from that list.
http://docs.python.org/lib/module-gc.html
-Miles
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 18, 11:31 am, Jason Baker <[EMAIL PROTECTED]> wrote:
> I have a class that I need to do some finalization on when it dies. I
> know I can use the __del__ method, but I seem to recall that it
> impedes garbage collection. Is this the case?
FWIW, I know a good number of top notch Python pro
On Fri, 18 Jul 2008 12:26:35 -0700, Jason Baker wrote:
> I don't necessarily need deterministic cleanup. And I plan on doing
> something like a close() method as well. But I'd just like to make
> sure nothing slips between the cracks. :)
`__del__()` isn't guaranteed to be called *at all*, so c
On Jul 18, 2:10 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Jul 2008 11:31:20 -0700, Jason Baker wrote:
> > I have a class that I need to do some finalization on when it dies. I
> > know I can use the __del__ method, but I seem to recall that it
> > impedes garbage collect
On Fri, 18 Jul 2008 11:31:20 -0700, Jason Baker wrote:
> I have a class that I need to do some finalization on when it dies. I
> know I can use the __del__ method, but I seem to recall that it
> impedes garbage collection. Is this the case?
`__del__()` is not a deterministic destructor. So for
I have a class that I need to do some finalization on when it dies. I
know I can use the __del__ method, but I seem to recall that it
impedes garbage collection. Is this the case?
(keep in mind that my code aims to be compatible with python 2.3 to
python 2.5)
--
http://mail.python.org/mailman/li
ts whose only references are from cycles which themselves
have no external references and no __del__methods, assuming that
garbage collection runs.
> __del__ methods (weakref callbacks too, for that matter) triggered
> while Python is tearing itself down at exit may suffer bizarre
>
[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:
>>
>> clas
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
[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__(s
[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:
&g
[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
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 no
26 matches
Mail list logo
