__del__ methods

[Jason Baker]

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)

[Marc 'BlackJack' Rintsch]

Re: __del__ methods

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 forget about reliable
automatic clean up. Do it yourself with an explicit call to a `close()`
method or something like that.

Ciao,
Marc 'BlackJack' Rintsch

[Jason Baker]

Re: __del__ methods

On Jul 18, 2:10 pm, Marc 'BlackJack' Rintsch <bj_...@gmx.net 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 collection.  Is this the case?

>
`__del__()` is not a deterministic destructor.  So forget about reliable
automatic clean up.  Do it yourself with an explicit call to a `close()`
method or something like that.
>
Ciao,
        Marc 'BlackJack' Rintsch

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. :)

[Marc 'BlackJack' Rintsch]

Re: __del__ methods

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 can't make sure
nothing slips between the cracks with it.

Ciao,
Marc 'BlackJack' Rintsch

[Raymond Hettinger]

Re: __del__ methods

On Jul 18, 11:31 am, Jason Baker <amnorv...@gmai l.comwrote:

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 programmers
who have programmed happily for years without ever using
__del__. There are ways to get it to work for you, but
it may be the smart thing to pretend that you've never
heard of it.

Raymond

[Robert Rawlins]

RE: __del__ methods

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 the C objects.

Instead

create a separate class which does nothing but track it's own desctruction

and reference that from the class which may be leaking.
>

>class Track(object):

> def __init__(self, parent):
> self.parentid = id(parent)
> self.parenttype = type(parent).__ name__
> def __del__(self):
> print "Destroyed <%s object at %s>" % (self.parenttyp e,
self.parentid)
>
>

>class C(object):

> def __init__(self):
> self._track = Track(self)
>

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
give me that en empty, non subclassed object doesn't?

However you should also consider that __del__ only lets you log when
objects are destroyed. Using weak references may be a more useful option

as

it will let you track which objects are not being destroyed: you can

easily

keep a dictionary of weak references to all existing objects of interest.
Check its length periodically to see whether objects are being leaked and
then inspect the objects themselves to see which ones have leaked.
>
You can use gc.get_referrer s() to find everything that references a
particular objects and gradually trace backwards until you find the

problem

reference (it is tricky though as any code which does this needs to ignore

its own references to the object in question).

Yes, that's a very nice concept and like you say gives you quite a nice
visual reference of what objects are and aren't being destroyed.

Cheers Duncan,

Robert

[Duncan Booth]

RE: __del__ methods

"Robert Rawlins" <robert.rawlins @thinkbluemedia .co.ukwrote:

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 give me that en empty, non subclassed object doesn't?
>

Habit: certain things (such as properties) don't work properly with
old-style classes, so it is good practice always to use new-style
classes and that way you won't forget to do it when it really does
matter.

>You can use gc.get_referrer s() to find everything that references a
>particular objects and gradually trace backwards until you find the

problem

>reference (it is tricky though as any code which does this needs to
>ignore

>

>its own references to the object in question).

>
Yes, that's a very nice concept and like you say gives you quite a
nice visual reference of what objects are and aren't being destroyed.
>

See

http://groups.google.co.uk/group/comp.lang.python/browse_thread/thread/394ba5b48f83ebfb/237dc92f3629dd9a#237dc92f3629dd9a

for the code (although I seem to remember that there are some problems
with that code so caveat emptor).

[Ben Finney]

Re: __del__ methods

"Robert Rawlins" <robert.rawlins @thinkbluemedia .co.ukwrites:

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 backward
compatibility with old code.

You need to create "new-style" classes
<URL:http://www.python.org/doc/newstyle/by inheriting from some
class that is part of the unified type hierarchy; if there is no
obvious candidate, 'object' is the recommended choice.

In Python 3.0, classic classes are no longer supported and this issue
goes away.

--
\ Q: “I've heard that Linux causes cancer...” Torvalds: “That's a |
`\ filthy lie. Besides, it was only in rats and has not been |
_o__) reproduced in humans.” —Linus Torvalds |
Ben Finney

[Robert Rawlins]

RE: __del__ methods

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
<URL:http://www.python.org/doc/newstyle/by inheriting from some
class that is part of the unified type hierarchy; if there is no
obvious candidate, 'object' is the recommended choice.

Thanks Ben,

This isn’t something I'd seen before (god that makes me feel stupid). I've always based my code off the odd example that's dotted around and hadn’t ever done any proper reading on these new type classes.

I've done a little reading this morning and really love a great deal of the concepts, I'll be upgrading my app to this spec in the next few days.

Robert

[Ben Finney]

Re: __del__ methods

"Robert Rawlins" <robert.rawlins @thinkbluemedia .co.ukwrites:

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, with some documentation
<URL:http://www.python.org/doc/>, and by working through the Python
tutorial <URL:http://www.python.org/doc/tut/>.

--
\ “I was married by a judge. I should have asked for a jury.” |
`\ —Groucho Marx |
_o__) |
Ben Finney

[Robert Rawlins]

RE: __del__ methods

Time to fix that, then, with some documentation

<URL:http://www.python.org/doc/>, and by working through the Python
tutorial <URL: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/pyt...le_classes.htm earlier this morning which was also a nice little resource.

Just about all of it makes sense at the moment, apart from the new constructor types which are constructors at a class level opposed to at instance level. I found this a little confusing but who knows.

Presumably this is where you would deal with setting things which exist in every instance of a class, and properties that can vary from instance to instance go into the standard __init_(), have I got that right?

Cheers Ben,

Robert

[Robert Rawlins]

RE: __del__ methods

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