Python attributeError on __del__

When __del__() method called, the Groupclass may be recovered by the garbage collection mechanism, so using Groupclass.xxx may failed. But you can access the count variable through self.__class__.count. Code likes below:

def __del__(self):
    self.__class__.count -= 1

Your __del__ method assumes that the class is still present by the time it is called.

This assumption is incorrect. Groupclass has already been cleared when your Python program exits and is now set to None.

Test if the global reference to the class still exists first:

def __del__(self):
    if Groupclass:
        Groupclass.count -= 1

or use type() to get the local reference:

def __del__(self):
    type(self).count -= 1

but do note that this means that the semantics for count change if Groupclass is subclassed (each subclass gets a .count attribute versus only Groupclass having a .count attribute).

Quoting from the __del__ hook documentation:

Warning: Due to the precarious circumstances under which __del__() methods are invoked, exceptions that occur during their execution are ignored, and a warning is printed to sys.stderr instead. Also, when __del__() is invoked in response to a module being deleted (e.g., when execution of the program is done), other globals referenced by the __del__() method may already have been deleted or in the process of being torn down (e.g. the import machinery shutting down). For this reason, __del__() methods should do the absolute minimum needed to maintain external invariants. Starting with version 1.5, Python guarantees that globals whose name begins with a single underscore are deleted from their module before other globals are deleted; if no other references to such globals exist, this may help in assuring that imported modules are still available at the time when the __del__() method is called.

If you are using Python 3, two additional notes apply:

• CPython 3.3 automatically applies a randomized hash salt to the str keys used in a globals dictionary; this also affects the order in which globals are cleaned up, and it could be that you see the problem on only some of the runs.

• CPython 3.4 no longer sets globals to None (in most cases), as per Safe Object Finalization; see PEP 442.