[Python-Dev] gc.garbage
M.-A. Lemburg
mal@lemburg.com
Fri, 30 Nov 2001 10:13:37 +0100
Neil Schemenauer wrote:
>
> Tim Peters wrote:
> > But I'd be keener to see new words spelling out which parts of the gc
> > interface are and aren't intended "to work" across releases ...
>
> All of them? :-) Seriously, there could come a time when GC can no
> longer be disabled.
Please don't remove this option ! Writing code which does not
introduce cycles or knows how to break them is fairly easy --
removing the option would make everyone pay for careless
programming of a few.
> The debugging and threshold stuff is fairly
> implementation dependent. get_referrers() and get_objects() are highly
> implementation dependent. I suppose gc.collect() should always be
> available. Anything else is fair game, IMHO.
>
> Incidentally, I can't say I'm happy with GC as it stands. It uses too
> much memory now that so many objects are tracked. I had worked on the
> idea of a separate heap for GC objects for a while but couldn't figure
> out how to make generational collection to work. As Don Beaudry's sig
> says: "so much code, so little time". :-)
Another reason not to remove the option.
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/