[Python-Dev] gc.garbage

[Tim Peters]

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