__del__ method being called in python when it is not expected

Question

I am new to python and have been working through the examples in Swaroop CH's "A Byte of Python". I am seeing some behavior with the __del__ method that is puzzling me.

Basically, if I run the following script (in Python 2.6.2)

class Person4:
    '''Represents a person'''
    population = 0

    def __init__(self, name):
        '''Initialize the person's data'''
        self.name = name
        print 'Initializing %s'% self.name

        #When the person is created they increase the population
        Person4.population += 1

    def __del__(self):
        '''I am dying'''
        print '%s says bye' % self.name

        Person4.population -= 1

        if Person4.population == 0:
            print 'I am the last one'
        else:
            print 'There are still %d left' % Person4.population


swaroop = Person4('Swaroop')
kaleem = Person4('Kalem')

using the Python console (or the Spyder interactive console) I see the following:

execfile(u'C:\1_eric\Python\test1.py')
Initializing Swaroop
Initializing Kalem

execfile(u'C:\1_eric\Python\test1.py')
Initializing Swaroop
Swaroop says bye
I am the last one
Initializing Kalem
Kalem says bye
I am the last one

Why is the __del__ method being called immediately after the __init__ on the second run?
I am guessing that since the same instance names ('swaroop' and 'kaleem') are being used that it is releasing the original instance and garbage collecting it. But, this seems to be playing havoc with the current population count.

What is going on here?
What is a good way to avoid this sort of confusion?
Avoid the use of __del__? Check for existing instance names before reusing them? ...

Thanks, Eric

Sometimes

You shouldn't rely on the __del__ method being called at any particular time anyway. In the future the garbage collector could change so that __del__ gets called at different times. – Entrammel

@Soviut (who had retagged this incorrectly): this has nothing to do with "classmethods" in Python. It does use a class attribute, but that's not the same thing. – Curable

Welcome to Stack Overflow! When you've received a good answer to your question, please "accept" the most helpful answer by clicking on the checkbox outline to the left of the answer. This indicates that you've received an answer that worked for you. Doing this helps increase your reputation on the site. – Blanka

Answer 1

There are a couple of things going on here. When your Person4 class is instantiated, it initialises its population class variable to 0. From your interactive console, you appear to be running your "test1.py" file multiple times. The second time you run it, the Person4 class is declared again which makes it technically different from the first one (even though it has the same name). That means it has its own independent population count.

Now, swaroop and kaleem are global variables, shared between both your instances of "test1.py". Python internally uses reference counting for most of its automatic garbage collection, so the original instance of the first Person4 class is not released until the second assignment to swaroop. Assigning to swaroop decrements the reference count for the first instance, causing __del__ to be called because the reference count is now zero. But because you're referring to Person4 by name inside __del__(), when the previous instance disappears it decrements the new Person4.population count, instead of the old Person4 population count.

Hopefully that made sense. I can see why this might be confusing to somebody learning Python. Your use of class variables at the same time as redefining the Person4 class using execfile() is further confusing matters. For what it's worth, I've written a lot of Python code and I don't think I've ever needed to use the __del__ special method.

Blanka

Answer 2

General advice: don't use __ del __ in Python. It can break garbage collection in a number of ways, esp. in the case of circular references between objects.

In your example, there're various issues related to the usage of execfile() - which is not a best practice - and the redefinition of global variables. By the way, if you really need to create a pseudo-destructor (i.e. a code that is invoked whenever the object gets garbage collected), write a so-called "finalizer" function (it's not properly a destructor) and invoke it using weakref.ref callback. It should NOT be an instance method of course, and remember that lambda actually creates a closure, hence be sure not to leak any reference to self in the callback! If you need data from the destroyed instance, use the func default argument approach, just be sure never to reference 'self' inside the lambda, otherwise it won't work.

from weakref import ref
from time import sleep

class Person4:
    '''Represents a person'''
    population = 0

    def __init__(self, name):
        '''Initialize the person's data'''
        self.name = name
        print 'Initializing %s'% self.name

        #When the person is created they increase the population
        Person4.population += 1

        self._wr = ref(self, lambda wr, name=self.name: Person4_finalizer(name))

def Person4_finalizer(name):
        '''I am dying'''
        print '%s says bye' % name

        Person4.population -= 1

        if Person4.population == 0:
            print 'I am the last one'
        else:
            print 'There are still %d left' % Person4.population

p1 = Person4("one")
p2 = Person4("two")
p3 = Person4("three")

del p2
del p3
sleep(5)

output (the sleep is there to help see what's happening):

Initializing one
Initializing two
Initializing three
two says bye
There are still 2 left
three says bye
There are still 1 left
one says bye
I am the last one

Sacci

Thanks Greg and Alan for the explanations, I now understand what is happening, and that using del has issues. One thing that still bothers me is that if I "forget" to del all of the globals in the above script and run the script twice in a row (inside the Spyder IDE, which uses execfile() ) I still see the finalizer being called right after the initializer, Initializing one one says bye I am the last one i.e. the cleanup of the "old" p1 happens after p1 is reassigned. I guess I need to be careful when reassigning "global" variables (or using temporary variables like "tempVar". – Sometimes

Better, you should remember that Python has no concept of "variables" in the sense that statically typed languages have. There're just objects and names which bind such objects - once an object is not referenced by anything, it will be destroyed - but there's no "memory location" whose value will be overwritten when you change the value - the "=" operator rebinds the name to a different reference instead. – Sacci