Hello. Sorry if this is noise. I expected __del__ out of function __del__ out of function __del__ out of function on following code, but actually I got out of function out of function out of function __del__ __del__ __del__ Is this expected behavoir? (I believed `a' would be freed after returned from f(), so I was suprised) If I remove the comment of gc.collect(), the code works as expected. /////////////////////////////// import gc class A: def __del__(self): print("__del__") def f(): a = A() def g(): a g() def main(): for _ in range(3): f() # gc.collect() print("out of function") if __name__ == '__main__': main()

Since g calls "itself" in its own scope, it is stored as one of its own cell vars, which creates a reference cycle. a is also part of its reference cycle for the same reason, so it must wait for garbage collection to be reclaimed. If g didn't keep a reference to its cell vars, closures wouldn't be possible, because the cell vars wouldn't survive the end of f's scope. (g doesn't have to be recursive, it's enough that it makes a reference to itself in its own scope: def f(): a = A() def g(): a g or even: def f(): a = A() def g(): a h h = g )

Thank you for explanation. The combination of inner function + method variable was very handy for me, but maybe I should refrain from using it lightly. :-(

A little followup. Attached script q112.py (some puzzle program) ate up my RAM (80MB) and never ran GC while solving. Current python GC looks at the number of GC objects, but GC object like set object can contain many non GC object, so... I feel it would be nice if there is better GC triger/timing.

Well, tracking memory consumption of each container would be better than simpling couting them, but it's much more complicated as well (not to mention that memory consumption can vary, so you must recalculate it periodically...).

Would it be possible for function self-reference cell vars to be weak references? This wouldn't solve the issue for co-recursive inner functions, but would at least prevent reference cycles for the more common case of simple recursive functions.

For anyone doing archaeology - this came up on python-dev about a year after this issue was filed: https://mail.python.org/pipermail/python-dev/2009-December/094439.html