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.) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
