[Neil Schemenauer]
Is there some way to prevent people from assigning to certain module variables?
[Tim]
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. ...
[Neil]
What would happen if it's not a list? PRINT_ITEM raises RuntimeError. I suppose the collector could do the same.
Sure, that would be fine.
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.
I meant "new words" in the docs, not on Python-Dev <wink>.
Incidentally, I can't say I'm happy with GC as it stands.
Well, you're young and hopeful -- you'll get over both. I have, and am indeed happy with GC as it stands.
It uses too much memory now that so many objects are tracked.
There I disagree, but subtly: it always used "too much" memory. The marginal memory cost in adding a gazillion new tracked types was minor, as very few programs have a gazillion frame objects or traceback objects or generator-iterator objects (etc) sitting around. The vast bulk of the damage was done the instant lists, tuples, dicts and instances got tracked. So it goes.
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.
Generational gimmicks are rare in non-copying collectors for this very reason, right?
As Don Beaudry's sig says: "so much code, so little time". :-)
Time for Don to change his sig -- his young and hopeful days should be long gone by now too <wink>.