Travis and others, In the course of trying to understand memory leaks in matplotlib I have been trying to understand a bit about the garbage collector. If I understand correctly, any container that can can hold references to other containers could lead to a reference cycle; if the container supports the gc mechanism, then the gc can at least find the cycles. If the containers do not have __del__ methods, then the gc can also break the cycles and reclaim the memory. (This also seems to imply that __del__ methods should be avoided if at all possible, and I don't understand the implications and applications of this.) I notice that numpy.ndarray does not support the gc, correct? And since an ndarray can hold other containers, it could lead to uncollectable cycles, correct? Did you decide not to include gc support because it is not actually needed or useful? If so, what am I missing? I don't think the lack of gc support in numpy has anything to do with the present leak problem in mpl, so I am asking about numpy partly out of curiosity, and partly in the hope that your answer will help me understand exactly when one really needs to worry about gc support in extension code--mpl has quite a bit of extension code, and relies on much outside extension code as well. The one little bit of extension code I wrote for numpy, the wrapper part of the contour routine, does not support the gc--and if this is a mistake, I want to know about it. (I am beginning to suspect that it should support the gc, although it is not part of our most basic problem at the moment.) Googling has not turned up much information beyond the standard python docs about the gc, extension code, and memory leaks in python. Thanks for whatever insight and advice you can provide. Eric