On Tue, Apr 27, 2010 at 2:58 PM, Chris Rebert <c...@rebertia.com> wrote: > On Tue, Apr 27, 2010 at 2:42 PM, Michal M <mich.mier...@googlemail.com> wrote: >> On 27 Kwi, 23:21, Duncan Booth <duncan.bo...@invalid.invalid> wrote: >>> Michal M <mich.mier...@googlemail.com> wrote: >>> > I've just found out that one of objects is not destroyed when it >>> > should be. This means that something was holding reference to this >>> > object or part of it (i.e. method). Is there any way to check what >>> > holds that reference? I am unable to do that just looking to the code >>> > or debugging it because it is pretty complicated, but I am able to >>> > invoke this situation again. >>> >>> See if this code helps: >>> >>> http://groups.google.com/group/comp.lang.python/browse_thread/thread/... >>> >>> It's pretty old so it may need some adjustment, but I wrote it >>> to figure out exactly that sort of problem. >> >> Thanks you for answers. >> I tried to use gc.get_referrers(self) in point in code when according >> to me object should be destroyed earlier but I did not see anything >> interesting. Then just realised that gc will not destroy object even >> when itself holds reference to his own method. >> >> For example >> >> class A(object): >> def a(self): >> pass >> def b(self): >> self.method = self.a >> def __del__(self): >> print "A object deleted" >> >>>> a = A() >>>> del a >> A object delted >>>> a = A() >>>> a.b() >>>> del a >> ... nothing ... >> >> I thought gc would discover such circle loops but apparently it did >> not. > > No, it does, you just didn't give it long enough; for performance > reasons, cyclical GC is only done every so often:
Addendum: Also, defining __del__ in your example was likely problematic: See http://docs.python.org/library/gc.html#gc.garbage - Chris -- http://mail.python.org/mailman/listinfo/python-list
