[Python-Dev] GC Changes

[Hrvoje Nikšić]

On Tue, 2007-10-02 at 11:30 +0100, Gustavo Carneiro wrote:
>         even large memory objects, there is always explicit
>         management.
>         cStringIO's "close" method provides a precedent.
> 
> I think close in real files is needed  not so much because you want to
> free memory, but that you want to prevent data loss by flushing the
> file buffer into the actual file at a certain point in time.

You can also do that with flush.  What is specific for close is that it
frees up the system resources occupied by the open file.  Calling it at
a known point in time ensures that these external resources aren't
occupied any longer than necessary, regardless of the object
deallocator's policies.  That is why open(filename).read() is
discouraged, despite being a useful idiom in throwaway scripts and
working just fine in CPython.

The fact that programmers need Pixbuf's memory released sooner rather
than later might indicate that Pixbuf would benefit from a "close"-like
method.  In any case, I trust your judgment on Pixbufs, but merely point
out that in general it is unwise to rely on the deallocator to release
resources where timing of the release matters.

>   And I suspect that cStringIO just added a close() method for
> compatibility with real files.  But of course I speculating here... 

That could be the case, but then the method could also be a no-op.  I
only brought up cStringIO as a precedent for a close method that works
with a memory-only object.  (StringIO's close also tries to arrange for
the buffer to be freed immediately, inasmuch as that is possible to
achieve in pure Python.)