On Thu, 24 Jun 1999, Guido van Rossum wrote:
How about introducing internal macros for explicit ob_refcnt accesses in the core?
What problem does this solve?
I assume Vladimir was trying to leave the door open for further ob_refcnt manipulation hooks later, like having objects manage their own refcounts. Until there's an actual problem to solve that requires this, though, i'm not sure it's necessary. Are there obvious reasons to want to allow this? * * * While we're talking about refcounts and all, i've had the argument quite successfully made to me that a reasonably written garbage collector can be both (a) simple and (b) more efficient than refcounting. Having spent a good number of work days doing nothing but debugging crashes by tracing refcounting bugs, i was easily converted into a believer once a friend dispelled the notion that garbage collectors were either slow or horribly complicated. I had always been scared of them before, but less so now. Is an incremental GC being considered for a future Python? I've idly been pondering various tricks by which it could be made to work with existing extension modules -- here are some possibilities: 1. Keep the refcounts and let existing code do the usual thing; introduce a new variant of PyObject_NEW that puts an object into the "gc-able" pool rather than the "refcounted" pool. 2. Have Py_DECREF and Py_INCREF just do nothing, and let the garbage collector guess from the contents of the structure where the pointers are. (I'm told it's possible to do this safely, since you can only have false positives, never false negatives.) 3. Have Py_DECREF and Py_INCREF just do nothing, and ask the extension module to just provide (in its type object) a table of where the pointers are in its struct. And so on; mix and match. What are everyone's thoughts on this one? -- ?!ng "All models are wrong; some models are useful." -- George Box