matplotlib-devel Mailing List for matplotlib

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