How do constructors and destructors work?

Question

I'm trying to understand this code:

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

    def __init__(self,name):
          //some statements and population += 1
    def __del__(self):
          //some statements and population -= 1 
    def sayHi(self):
        '''grettings from person'''
        print 'Hi My name is %s' % self.name

    def howMany(self):
        '''Prints the current population'''
        if Person.population == 1:
            print 'i am the only one here'
        else:
            print 'There are still %d guyz left ' % Person.population
rohan = Person('Rohan')
rohan.sayHi()
rohan.howMany()


sanju = Person('Sanjivi')
sanju.howMany()

del rohan # am i doing this correctly? 

How does the destructor get invoked -- automatically or do I have to add something in the "main" program/class like above?

Output:

Initializing person data
******************************************
Initializing Rohan
******************************************
Population now is: 1
Hi My name is Rohan
i am the only one here
Initializing person data
******************************************
Initializing Sanjivi
******************************************
Population now is: 2
In case Person dies:
******************************************
Sanjivi Bye Bye world
there are still 1 people left
i am the only one here
In case Person dies:
******************************************
Rohan Bye Bye world
i am the last person on earth
Population now is: 0

If required I can paste the whole lesson as well. I'm learning from: http://www.ibiblio.org/swaroopch/byteofpython/read/

Answer 1

Here is a slightly opinionated answer.

Don't use __del__. This is not C++ or a language built for destructors. The __del__ method really should be gone in Python 3.x, though I'm sure someone will find a use case that makes sense. If you need to use __del __, be aware of the basic limitations per http://docs.python.org/reference/datamodel.html:

• __del__ is called when the garbage collector happens to be collecting the objects, not when you lose the last reference to an object and not when you execution del object.
• __del__ is responsible for calling any __del__ in a superclass, though it is not clear if this is in method resolution order (MRO) or just calling each superclass.
• Having a __del__ means that the garbage collector gives up on detecting and cleaning any cyclic links, such as losing the last reference to a linked list. You can get a list of the objects ignored from gc.garbage. You can sometimes use weak references to avoid the cycle altogether. This gets debated now and then: see http://mail.python.org/pipermail/python-ideas/2009-October/006194.html.
• The __del__ function can cheat, saving a reference to an object, and stopping the garbage collection.
• Exceptions explicitly raised in __del__ are ignored.
• __del__ complements __new__ far more than __init__. This gets confusing. See http://www.algorithm.co.il/blogs/index.php/programming/python/python-gotchas-1-del-is-not-the-opposite-of-init/ for an explanation and gotchas.
• __del__ is not a "well-loved" child in Python. You will notice that sys.exit() documentation does not specify if garbage is collected before exiting, and there are lots of odd issues. Calling the __del__ on globals causes odd ordering issues, e.g., http://bugs.python.org/issue5099. Should __del__ called even if the __init__ fails? See http://mail.python.org/pipermail/python-dev/2000-March/thread.html#2423 for a long thread.

But, on the other hand:

• __del__ means you do not forget to call a close statement. See http://eli.thegreenplace.net/2009/06/12/safely-using-destructors-in-python/ for a pro __del__ viewpoint. This is usually about freeing ctypes or some other special resource.

And my pesonal reason for not liking the __del__ function.

• Everytime someone brings up __del__ it devolves into thirty messages of confusion.
• It breaks these items in the Zen of Python:
  • Complex is better than complicated.
  • Special cases aren't special enough to break the rules.
  • Errors should never pass silently.
  • In the face of ambiguity, refuse the temptation to guess.
  • There should be one-- and preferably only one --obvious way to do it.
  • If the implementation is hard to explain, it's a bad idea.

So, find a reason not to use __del__.