[Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC

[noreply@sourceforge.net]

Patches item #477059, was opened at 2001-10-31 20:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: __del__ on new classes vs. GC

Initial Comment:
Neil, excuse me for the assignment. You can reassign
this to Tim if you don't have time; I know *I* won't
get to it in time for 2.2b2.

I recently added __del__ for new-style classes, but I
believe this would require the same kind of exception
from the GC code as classic instances with a __del__
handler. Of course, it's a bit more difficult since
*any* heap-based type can have a __del__ handler...

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-11-01 06:26

Message:
Logged In: YES 
user_id=6380

Thanks -- I thought it would probably shallow but wasn't
sure. I've fixed this now.

Do I understand correctly that objects with a __del__
attribute are not GC'ed at all (if part of a cycle)? Isn't
that sad? Shouldn't we at least attempt to recover the
memory without calling the finalizers?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-31 22:13

Message:
Logged In: YES 
user_id=31435

Guido, I expect this is shallow, confined to move_finalizers
().  It's looking for objects that both (a) have 
a "__del__" attr, and (b) pass PyInstance_Check().  An 
instance of a new-style class with __del__ passes the 
former test but not the latter, and I believe that's all 
the repair needed (but am blanking out on exactly what 
should be checked instead -- it will occur to me overnight 
<wink> -- I assume the existing PyInstance_Check is really 
just trying to avoid the expense of general 
PyObject_HasAttr when the latter has no chance of 
succeeding).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470