A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2007-October/074846.html below:

[Python-Dev] GC Changes

[Python-Dev] GC ChangesHrvoje Nikšić hrvoje.niksic at avl.com
Tue Oct 2 12:24:11 CEST 2007
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.



More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4