In the sample code if one comments out the __del__ method in the class the leak does not occur. That is not to say it can't happen I suppose in a more complicated code example but I believe the __del__ is a required piece. This test was performed without the gc.collect() being present. I ran System Monitor on Ubuntu and watched the python process after each edit and monitored memory size to verify. So the only way I got the leak was to have the __del__method present on the class in the exec example and not have the gc.collect() call.
I left the process running with the leak (__del__ present in class and gc.collect() commented out) and it got to 3 GB of process space so the collector never ran. The system was showing all the signs of a machine in trouble from memory pressure, I have 4 GB of physical memory. The size builds quite rapidly. This is an old article published as the gc module was added to Python that explains a bit about gc in Python. http://arctrix.com/nas/python/gc/ Because it is old it may not be 100% accurate today but does go into the problem some better than the reference documentation. This article was decent as well http://www.algorithm.co.il/blogs/programming/python-gotchas-1-__del__-is-not-the-opposite-of-__init__/ Ron
