good article, esp. the "The trouble with Finalizers" part
2011/1/10 ron_m <ron.mco...@gmail.com>: > 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 > > > >