Why is this a mem leak?

[Tim Peters]

[Steve <steve at hotmail.com>]
...
> Another question:
> 
> I get the following when I set DEBUG in gc to DEBUG_LEAK:
> 
> GARBAGE:
> gc: uncollectable <JCollector instance at 0x403a7f2c>
> gc: uncollectable <NCollector instance at 0x403fa2cc>
> gc: uncollectable <dict 0x403a9c64>
> gc: uncollectable <dict 0x403f9934>
> gc: uncollectable <instancemethod 0x403a5dec>
> gc: uncollectable <instancemethod 0x403aa0f4>
> 
> this was after calling a method foo() which created two instances of a
> single class, which then created the dictionaries and instancemethods
> named above. After foo() ended, I would have thought that these
> instances/objects would have been collected. I called gc.collect()
> explicitly two times but the gc.garbage list still held the same list as
> 'garbage'. Does 'uncollectable' here means that these objects will never
> be collected?

No, but it does mean it's very likely they'll never be collected --
unless you do something to make them collectable.

> Why is that?

The gc module is documented in the Library Reference Manual.  The docs
for gc.garbage there should answer all your questions here.

> They're not bound by anything once foo() exits.

> How can I make sure the memory allocated for this junk is deleted
> (since I want to run foo() in a loop).

Read the gc.garbage docs.  Then don't create cycles containing objects
with __del__ methods, or, if you think you must, do what the docs say
to do <wink>.