"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > Throwing them out without careful consideration is a bad >idea--ref-counting is _not_ simply one GC implementation among many, it >actually offers useful semantics and the cost of giving up those >semantics should be considered before throwing out refcounting.
It's too late to consider anything before throwing out refcounting. Refcounting has already been thrown out (in Jython, IronPython, and maybe PyPy). It's just an implementation artifact of CPython and MANY other language implementations have gotten along perfectly well without it. > (1) I think is here to stay, if you're going to tell programmers that > their destructors can't make program-visible changes (e.g. closing the > database connection when a dbconn is destroyed), that's a _huge_ change > from current practice that needs serious debate. We had that debate already (PEP 343). Yes, there is some sloppy current practice by CPython users that relies on the GC to close the db conn. That practice already fails in several other Python implementations and with PEP 343, we now have a clean way to fix it. I don't understand why you're so fixated on keeping the sloppy method around. The benefit is marginal at best. If you want stack-like deallocation of something, ask for it explicitly. -- http://mail.python.org/mailman/listinfo/python-list