Python's garbage collection was Re: Python reliability

Paul Rubin http
Tue Oct 11 23:42:51 CEST 2005


aleax at mail.comcast.net (Alex Martelli) writes:
> > Has anyone looked into using a real GC for python? ...
> > lot more complexity in the interpreter itself, but it would be faster,
> > more reliable, and would reduce the complexity of extensions.
> 
> ???  It adds no complexity (it's already there), it's slower, it is, if
> anything, LESS reliable than reference counting (which is way simpler!),
> and (if generalized to deal with ALL garbage) it might make it almost
> impossible to write some kinds of extensions (ones which need to
> interface existing C libraries that don't cooperate with whatever GC
> collection you choose).  Are we talking about the same thing?!

I've done it both ways and it seems to me that a simple mark/sweep gc
does require a lump of complexity in one place, but Python has that
anyway to deal with cyclic garbage.  Once the gc module is there, then
extensions really do seem to be simpler to right.  Having extensions
know about the gc is no harder than having them maintain reference
counts, in fact it's easier, they have to register new objects with
the gc (by pushing onto a stack) but can remove them all in one go.
Take a look at how Emacs Lisp does it.  Extensions are easy to write.



More information about the Python-list mailing list