返回信息流咋就会出来 异常 呢？代码如下，高手支招啊：）
class p:
val=0
namelist=[]
def __init__(self,name):
self.name=name
p.val+=1
p.namelist.append(name)
print self.name, p.val, p.namelist
def __del__(self):
p.val-=1
p.namelist.remove(self.name)
print self.name, p.val, p.namelist
class s(p):
def __init__(self,name):
p.__init__(self,name)
def __del__(self):
p.__del__(self)
if __name__ == '__main__':
s3 = s('s3')
p1 = p('p1')
这是一条镜像帖。来源：北邮人论坛 / soft-design / #24240同步于 2008/3/3
该镜像源已超过 30 天没有更新，可能在源站已被删除。
SoftDesign机器人发帖
[求助]python写了个继承的测试，为什么会有exception？
ericyosho
2008/3/3镜像同步2 回复
订阅后，新回复会通过你的通知中心匿名送达。
2 条回复
refs: http://pyref.infogami.com/__del__
__del__(self)
Called when the instance is about to be destroyed. This is also called a destructor. If a base class has a __del__() method, the derived class's __del__() method, if any, must explicitly call it to ensure proper deletion of the base class part of the instance. Note that it is possible (though not recommended!) for the __del__() method to postpone destruction of the instance by creating a new reference to it. It may then be called at a later time when this new reference is deleted. It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits.
Note: "del x" doesn't directly call x.\_\_del\_\_() -- the former decrements the reference count for x by one, and the latter is only called when x's reference count reaches zero. Some common situations that may prevent the reference count of an object from going to zero include: circular references between objects (e.g., a doubly-linked list or a tree data structure with parent and child pointers); a reference to the object on the stack frame of a function that caught an exception (the traceback stored in sys.exc\_traceback keeps the stack frame alive); or a reference to the object on the stack frame that raised an unhandled exception in interactive mode (the traceback stored in sys.last\_traceback keeps the stack frame alive). The first situation can only be remedied by explicitly breaking the cycles; the latter two situations can be resolved by storing None in sys.exc\_traceback or sys.last\_traceback. Circular references which are garbage are detected when the option cycle detector is enabled (it's on by default), but can only be cleaned up if there are no Python-level __del__() methods involved. Refer to the documentation for the [ gc module][1] for more information about how __del__() methods are handled by the cycle detector, particularly the description of the garbage value.
Warning: Due to the precarious circumstances under which __del__() methods are invoked, exceptions that occur during their execution are ignored, and a warning is printed to sys.stderr instead. Also, when __del__() is invoked in response to a module being deleted (e.g., when execution of the program is done), other globals referenced by the __del__() method may already have been deleted. For this reason, __del__() methods should do the absolute minimum needed to maintain external invariants. Starting with version 1.5, Python guarantees that globals whose name begins with a single underscore are deleted from their module before other globals are deleted; if no other references to such globals exist, this may help in assuring that imported modules are still available at the time when the __del__() method is called.
重点是最后一段
这样啊，竟然和 java 里面的 finalize() 差不多，不可靠……
是不是垃圾回收机制都有这个问题啊：）
试了一下，把sys.stderr关掉还没有用，一定要把sys.__stderr__关掉才能把 warning 去掉。