[hristian Tismer]
... Even better: Refcounting can lead to many new optimizations if we pay the cost to make INCREF/DECREF into methods. It has its cost (about 10 percent less pystones), but massive long-term benefits.
The GC patch Guido forced <wink> me to look at is based on the observation that it's impossible to create cyclic trash unless a decref leaves a nonzero refcount. So the patch adds a function call to the DECREF macro (if the new refcount is > 0, the object must be added to the set of "suspicious" objects; else the object must be removed from that set). So it roughly adds the cost of a method call to each decref anyway. You would think it adds less <wink>, but "the set" now is represented as a splay tree, so *gobs* of hairy code get executed in either case (splay trees do mutating rotations even on a lookup).
... Conclusion: I vote for a kind of GC that does just what refcounts cannot do, but please keep with the refcounts.
I like 'em too! BTW, Toby posted (at least an earlier version of) the patch to c.l.py, if anyone else wants to dig into it (I may have mentioned before that I'm short on time <wink>).