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/