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

noreply@sourceforge.net noreply@sourceforge.net
Wed, 31 Oct 2001 22:13:15 -0800


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: 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