[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/