Tim Peters wrote: > Neil Schemenauer: > > Is there some way to prevent people from assigning to certain module > > variables? > > Not that I know of. If you're terribly concerned, gc could look up > "garbage" in its dict on each access. That's what, e.g., PRINT_ITEM does > with sys.stdout. Then it would also have to check that it's a list, etc. What would happen if it's not a list? PRINT_ITEM raises RuntimeError. I suppose the collector could do the same. > 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. 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". :-) Neil
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