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:
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.
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]
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.
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:
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
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? :-)
I wish the C API hadn't been changed for 2.2, rendering useless all code that had been created to support GC in 2.0 and 2.1.
Regards, Martin
[Martin v. Loewis]
I wish the C API hadn't been changed for 2.2, rendering useless all code that had been created to support GC in 2.0 and 2.1.
Would we really need more than one hand to count all that code <0.9 wink>?
Mine was among it (in pyexpat), and I really hate looking at the code now. Not only need I support two versions of Unicode (i.e. having or not having it), but also three versions of GC, all in a single file.
Regards, Martin
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.
[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>.
-
M.-A. Lemburg -
Martin v. Loewis -
Neil Schemenauer -
Tim Peters -
Tim Peters