[Python-Dev] Cyclic GC issues

Jason Evans jasone at canonware.com
Wed Oct 13 16:54:04 CEST 2004


On Mon, Oct 11, 2004 at 11:34:34PM -0400, Tim Peters wrote:
> [Tim Peters]
> >> I think you're in for a rude awakening if you expect any language's gc
> >> support to help you manage arbitrary blobs of memory obtained from the
> >> system malloc().
>  
> [Jason Evans]
> > I don't expect that.  What I do expect is for there to be clean and
> > efficient mechanisms for integrating custom Python object types into
> > Python.  Python more or less meets this expectation.
> 
> OK ... but you must want more than just that, else this thread
> wouldn't have started <wink>.

I initially started this thread thinking that I had some useful suggestions
about how Python's GC might be modified.  Had I realized in advance that my
suggestions were based on my own misconceptions about Python's GC, I would
not have bothered the people in this forum.  I apologize for reducing the
signal to noise ratio of python-dev.

> > Many of the issues I ran into had to do with the impedence mismatch between
> > my previous experience and the way Python works.
> 
> I sure believe that.  Python's cyclic gc is unusual in several respects.

Indeed.  This brings up a question about documentation: as far as I know,
I've read all of the available documentation regarding cyclic GC (the
"Supporting cyclic garbage collection" section of "Extending and Embedding
the Python Interpreter"), but those docs came nowhere near giving me an
adequate understanding of the design rationale behind the cyclic GC.  Did I
overlook some documentation?

Of course, it may be that I am actually at a cognitive disadvantage to
someone who has only experienced Python's memory management strategy...

> > I appreciate you taking the time to respond to me, especially since you've
> > helped me gain a deeper understanding of how Python's GC works.  However,
> > please get it out of your mind that I am incompetent and/or set in my ways.
> 
> Those aren't in my head.  I do think you're so steeped in the details
> of your code that you're not nearly as successful at communicating the
> *salient* points as you think you are, though.  I'm so steeped in the
> details of Python's gc that a similar claim could easily be made of
> me.  I don't expect it to be clear the first time, though, so play
> 20-questions trying to tease out what you really need to know about
> it.  If it's any consolation, this process has been painful on both
> sides <wink>.

My critical error in trying to communicate the salient points of the Crux
code was that I didn't realize the importance of comminicating the fact
that the trees are implemented as a combination of separated low level tree
data structures and Python wrappers to the low level implementation.

Thanks for your help, Tim.

Jason


More information about the Python-Dev mailing list