Bazaar on IronPython

Martin Pool mbp at sourcefrog.net
Tue Jun 30 02:04:17 BST 2009


2009/6/30 Stephen J. Turnbull <stephen at xemacs.org>:
> Martin (gzlist) writes:
>
>  > Just so we're all on the same page with the terminology, that's
>  > relying on the refcounting to close the file, not the GC.

I think he meant "GC in general".  I think Python people do sometimes
use the term to mean non-refcounting-gc, a kind of metonymy.

> I don't understand the point of this distinction.  Refcounting is one
> of the standard algorithms for GC (with the well-known defect that
> reference cycles never get collected).  AIUI, for the purpose of this
> discussion the point is that we have come to expect timely
> finalization of open file handles.  That happens to occur in the
> CPython case because of file handles are refcounted *and* a refcount
> of 0 triggers immediate finalization, but that is not essential.
> Refcounting is neither necessary nor sufficient for early finalization
> of file handles by GC.
>
> All that matters here is that early finalization of file handles is an
> empirical fact of the CPython GC implementation that we can't expect
> in other GC schemes.

Yes, that seems to be true.  You can "get away with" not explicitly
closing files more in CPython than IronPython, it seems.  You can also
get away with it more often on Unix than on Windows because amongst
other things deleting or replacing the file will not fail because it's
still open.  However, our general approach is that we don't rely on
getting away with it, therefore we should fix these to be try/finally
blocks.

-- 
Martin <http://launchpad.net/~mbp/>



More information about the bazaar mailing list