Tom Anderson <[EMAIL PROTECTED]> wrote: ... > Has anyone looked into using a real GC for python? I realise it would be a
If you mean mark-and-sweep, with generational twists, that's what gc uses for cyclic garbage. > 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?! > So python doesn't use the old SmallTalk 80 SmallInteger hack, or similar? > Fair enough - the performance gain is nice, but the extra complexity would > be a huge pain, i imagine. CPython currently is implemented on a strict "minimize all tricks" strategy. There are several other implementations of the Python language, which may target different virtual machines -- Jython for JVM, IronPython for MS-CLR, and (less mature) stuff for the Parrot VM, and others yet from the pypy project. Each implementation may use whatever strategy is most appropriate for the VM it targets, of course -- this is the reason behind Python's refusal to strictly specify GC semantics (exactly WHEN some given garbage gets collected)... allow such multiple implementations leeway in optimizing behavior for the target VM(s). Alex -- http://mail.python.org/mailman/listinfo/python-list
