__del__ not called?

[Gregor Horvath]

Hi,

I do not understand why __del__ does not get executed in the following
example.

test.py:

#!/usr/bin/python
class A(object):
def __init__(self):
print "init"

def __del__(self):
print "del"

test1.py

#!/usr/bin/python
import test

class B(object):
a = test.A()

Running test1.py outputs:

init

the "del" is missing.

I suppose the a object should be garbage collected!?
--
Gregor

[Felipe Almeida Lessa]

Em Seg, 2006-03-13 Ã*s 08:21 +0100, Gregor Horvath escreveu:

Hi,

I do not understand why __del__ does not get executed in the following
example.

It only collects when there are no references:

class A(object): .... def __init__(self):
.... print "A's init"
.... def __del__(self):
.... print "A's del"
.... a = A() A's init del a A's del class B(object): .... a = A()
....
A's init del B
# We'll to tell him to collect the garbage here, but .... # usually it should not be necessary.
.... import gc gc.collect() A's del
20

--
"Quem excele em empregar a força militar subjulga os exércitos dos
outros povos sem travar batalha, toma cidades fortificadas dos outros
povos sem as atacar e destrói os estados dos outros povos sem lutas
prolongadas. Deve lutar sob o Céu com o propósito primordial da
'preservação' . Desse modo suas armas não se embotarão, e os ganhos
poderão ser preservados. Essa é a estratégia para planejar ofensivas."

-- Sun Tzu, em "A arte da guerra"

[Gregor Horvath]

Felipe Almeida Lessa schrieb:

del B
# We'll to tell him to collect the garbage here, but

... # usually it should not be necessary.

Thanks. If I do

del B

then the __del__ of A gets called.
That surprises me. I thought that B gets del'd by python when it goes
out of scope?

Do I manually have to del all class objects, so that their class
attributes get gc'd ????

--
Gregor

[Duncan Booth]

Gregor Horvath wrote:

#!/usr/bin/python
class A(object):
def __init__(self):
print "init"

def __del__(self):
print "del"

test1.py

#!/usr/bin/python
import test

class B(object):
a = test.A()

Running test1.py outputs:

init

the "del" is missing.

I suppose the a object should be garbage collected!?

No, Python doesn't run the garbage collector when it is exiting. What it
does is to delete all the globals from each module in turn. So:

C:\Python24>pyt hon
Python 2.4.2c1 (#66, Sep 21 2005, 15:16:11) [MSC v.1310 32 bit (Intel)] on
win32

Type "help", "copyright" , "credits" or "license" for more information.

class A(object): .... def __init__(self):
.... print "init"
.... def __del__(self):
.... print "del called"
.... a = A() init ^Z
del called

C:\Python24>

In this case the del method is called as 'a' is deleted, but if you create
a circular reference a does not get destroyed:
class A(object): .... def __init__(self):
.... print "init"
.... def __del__(self):
.... print "del called"
.... a = A() init a.ref = a
^Z

C:\Python24>

What is less obvious is that new style classes always include circular
references, so a class is never detroyed until the garbage collector runs.
A.__mro__ is a tuple which includes A, and there is probably something else
I've forgotten (for an empty and otherwise unreferenced class
getrefcount(old styleclass) returns 2, getrefcount(new styleclass) returns
5).

Of course, if your __del__ method actually does get invoked during program
exit you have to be pretty careful what you do: the chances are any global
variables you used in __del__ have already been destroyed in particular any
modules you imported may have been deleted. In short, don't rely on
anything much being possible from __del__ called this way.

[Gregor Horvath]

Duncan Booth schrieb:

What is less obvious is that new style classes always include circular
references, so a class is never detroyed until the garbage collector runs.
Thanks. I tried the same example with old style classes and A.__del__
gets correctly called.
Of course, if your __del__ method actually does get invoked during program
exit you have to be pretty careful what you do: the chances are any global
variables you used in __del__ have already been destroyed in particular any
modules you imported may have been deleted. In short, don't rely on
anything much being possible from __del__ called this way.

I wanted to close a database connection, which is opend by __init__.

But what happens to my database connection (instance attributes of A)
when __del__ is never called?

--
Greg

[Tim Peters]

[Duncan Booth]

No, Python doesn't run the garbage collector when it is exiting.
Actually, it does. What it doesn't do is call the garbage collector
twice when it exits, although it used to ;-)
What it does is to delete all the globals from each module in turn. So:

Yup. The code is in function Py_Finalize(). Here's the relevant snippet:

...
PyGC_Collect();

/* Destroy all modules */
PyImport_Cleanu p();

/* Collect final garbage. This disposes of cycles created by
* new-style class definitions, for example.
* XXX This is disabled because it caused too many problems. If
* XXX a __del__ or weakref callback triggers here, Python code has
* XXX a hard time running, because even the sys module has been
* XXX cleared out (sys.stdout is gone, sys.excepthook is gone, etc).
* XXX One symptom is a sequence of information-free messages
* XXX coming from threads (if a __del__ or callback is invoked,
* XXX other threads can execute too, and any exception they encounter
* XXX triggers a comedy of errors as subsystem after subsystem
* XXX fails to find what it *expects* to find in sys to help report
* XXX the exception and consequent unexpected failures). I've also
* XXX seen segfaults then, after adding print statements to the
* XXX Python code getting called.
*/
#if 0
PyGC_Collect();
#endif

The first PyGC_Collect() runs, then what you described runs ("destroy
all modules"), and then PyGC_Collect() _doesn't_ run again. As the
comment says, it's the second run of PyGC_Collect() that _would_ get
rid of dead module-level new-style classes, were it to run.

Alas, as the XXX comments say, too much of the interpreter has been
destroyed by PyImport_Cleanu p() for __del__ and weakref callbacks to
execute sanely, so we have to skip it. And, of course, module-level
objects _aren't_ trash before PyImport_Cleanu p() runs. Therefore
module-level objects involved in reference cycles never trigger
__del__ or weakref callbacks as a side effect of Python exiting, and
new-style classes are (as you said) always involved in reference
cycles.

[Duncan Booth]

Gregor Horvath wrote:

Of course, if your __del__ method actually does get invoked during
program exit you have to be pretty careful what you do: the chances
are any global variables you used in __del__ have already been
destroyed in particular any modules you imported may have been
deleted. In short, don't rely on anything much being possible from
__del__ called this way.

I wanted to close a database connection, which is opend by __init__.

But what happens to my database connection (instance attributes of A)
when __del__ is never called?

First off, never depend on __del__ to do anything critical. The only
guarantee about the __del__ method on an object is that it will be called
zero, one, or more times. (Admittedly you have to work a bit to get it
called more than once.)

If you have a resource which absolutely must be tidied up, then always put
the code which accesses that resource inside a try..finally construct. If
it is something pretty global to your program than that try..finally might
have to be at the outermost level of your program:

try:
main()
finally:
cleanup()

(In Python 2.5 you will be able to use a 'with' construct instead, but
unfortunately we still have to wait a bit for that to become common usage).

Without knowing more about the specific database connection, I can't tell
you what happens if you don't explicitly close it. I would hope that it
will tidy itself up, but if your code keeps anything cached locally to be
written out then obviously that might not get written.

If the database supports transactions (and it should), then I would expect
anything modified in a transaction which has been commited will be written
correctly, and everything modified in a transaction which has not been
commited will be discarded: closing (or not) the database should be pretty
well irrelevant.

[Gregor Horvath]

Duncan Booth schrieb:

First off, never depend on __del__ to do anything critical. The only

Thanks to all of you!
Everything's clear now!

--
Greg

[bruno at modulix]

Gregor Horvath wrote:

Felipe Almeida Lessa schrieb:

>del B
># We'll to tell him to collect the garbage here, but
... # usually it should not be necessary.

Thanks. If I do

del B

then the __del__ of A gets called.
That surprises me.

Why ?
I thought that B gets del'd by python when it goes
out of scope?
It does. What you have to understand here is that in your script, B
being in the global (read : module) scope, it doesnt goes out of scope
before the script's execution's done. By that time, it's too late to do
anything with stdin/stdout/stderr.

Just add this to the script:

def foo():
b = B()
print "in foo"

foo()
Do I manually have to del all class objects, so that their class
attributes get gc'd ????

Absolutely not. The only times I use del is when I want to cleanup a
namespace from temp vars no longer used (usually a module's namespace
with some hairy tricks at load time).

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"