[EMAIL PROTECTED] (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. -- http://mail.python.org/mailman/listinfo/python-list
