On 02/10/2007, Hrvoje Nikšić <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-10-02 at 10:50 +0100, Gustavo Carneiro wrote: > > Correct. And that reminds me of the limitation of the the Python GC: > > it doesn't take into account how much memory is being indirectly > > retained by a Python Object. Like in the example I already gave, > > gtk.gdk.Pixbuf can easily hold hundreds of megabytes, yet the GC gives > > it as much consideration as it does to a simple python integer object > > which is several orders of magnitude smaller. > > That sounds like a case for the Pixbuf object to have a "close" method > (not necessarily called that) that releases the resources. The point of > GC is that you normally don't care if memory is released sooner or > later; for stuff you do care about, such as files, shared memory, or > 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. And I suspect that cStringIO just added a close() method for compatibility with real files. But of course I speculating here... -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert
_______________________________________________ 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
