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