
I notice the gc docs say: The following variable is provided for read-only access: ^^^^^^^^^^^^^^^^ garbage A list of objects which the collector found to be unreachable ... This isn't clear to me. When I find finalizer cycles in gc.trash, I want to clean them up by breaking the cycles. Unless I remove the instances from gc.trash too, their appearance in that list keeps them alive despite that the cycles are broken. But "read-only access" seems to imply "don't mutate", and I don't believe that was intended. True? False?

Tim Peters wrote:
It's not clear because it's nonsense. I think I mean to say something about the gc.garbage binding. If you do something like: gc.garbage = "ha ha" then the list is garbage is forever inaccessible from within Python. Is there some way to prevent people from assigning to certain module variables? That would be the correct way to fix it, IMHO. Neil

[Neil Schemenauer, on the gc.garbage docs as of about a week ago]
I've since tried to repair the docs, to point out that rebinding gc.garbage is a Bad Idea but mutating it may be a Good one. BTW, I expect it's more likely people will get in trouble via: gc.garbage = [] I expect that because I did it once <wink>.
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. 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 ...

Tim Peters wrote:
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

Neil Schemenauer wrote:
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.
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/

[Neil Schemenauer]
Is there some way to prevent people from assigning to certain module variables?
[Tim]
[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 ...
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>.

Tim Peters wrote:
It's not clear because it's nonsense. I think I mean to say something about the gc.garbage binding. If you do something like: gc.garbage = "ha ha" then the list is garbage is forever inaccessible from within Python. Is there some way to prevent people from assigning to certain module variables? That would be the correct way to fix it, IMHO. Neil

[Neil Schemenauer, on the gc.garbage docs as of about a week ago]
I've since tried to repair the docs, to point out that rebinding gc.garbage is a Bad Idea but mutating it may be a Good one. BTW, I expect it's more likely people will get in trouble via: gc.garbage = [] I expect that because I did it once <wink>.
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. 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 ...

Tim Peters wrote:
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

Neil Schemenauer wrote:
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.
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/

[Neil Schemenauer]
Is there some way to prevent people from assigning to certain module variables?
[Tim]
[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 ...
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>.
participants (5)
-
M.-A. Lemburg
-
Martin v. Loewis
-
Neil Schemenauer
-
Tim Peters
-
Tim Peters