>I think 'resuscitation' might be a better metaphor. The term 'resurrection' is not my invention, but well established: http://en.wikipedia.org/wiki/Object_resurrection
I well understand why Antoine objects to calling it "resurrection" in CPython due to implementation specific reasons. But in the above article (which I consider rather detailed) I can't find anything stating that an object's ref-count must drop to zero at any time in order to call it "resurrected". In contrast, it clarifies that objects can not only resurrect themselves: "...which may in turn make that object or another garbage object (reachable from the object with a finalizer) reachable again" "If this happens, the referenced object – which is not necessarily the finalized object – is no longer garbage, and cannot be deallocated" > "x2" does *not* have its refcount drop to zero, since it is still > referenced by x. In other words, "x2" can only be on a "kill list" > after "x" has been finalized, which can only be *after* __del__ was > executed. x resurrects x2 in the sense that it must "actively" have an action in its finalizer that establishes a new reference to x2 in non-garbage or environment memory. Otherwise x as the "final life support link" of x2 would cause x2's ref count *actually* drop to zero in the next step. I never wanted this to become a discussion about the definition of object resurrection. I just wanted to understand which details in different behavior (such as weakref breaking) are okay and which are bugs (as breaking consistency of id() in Jython). Regards -Stefan > Gesendet: Montag, 27. Oktober 2014 um 23:36 Uhr > Von: "Terry Reedy" <tjre...@udel.edu> > An: python-dev@python.org > Betreff: Re: [Python-Dev] results of id() and weakref.getweakrefs() sometimes > break on object resurrection > > On 10/27/2014 12:23 PM, Stefan Richthofer wrote: > > > >> You mean Jython deletes instance attributes before calling __del__ ? > > > > No. I think the term of "object resurrection" usually does not mean > > bringing > > back a deleted object in the sense that memory was already freed. > > I think it rather means that nothing referred to an object, so it was on > > the > > "kill-list" of gc or zero-ref-count macro. > > In either case, there is a final reference keeping the object alive, > like an hospital patient kept alive by a final link with a life-support > machine. I think 'resuscitation' might be a better metaphor. > > -- > Terry Jan Reedy > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.de > _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
