[Python-Dev] PEP 442: Safe object finalization (original) (raw)

Eli Bendersky eliben at gmail.com
Sat May 18 15:56:26 CEST 2013

On Sat, May 18, 2013 at 6:47 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

On Sat, 18 May 2013 06:37:54 -0700 Eli Bendersky <eliben at gmail.com> wrote: > Great PEP, I would really like to see this happen as it defines much saner > semantics for finalization than what we currently have. One small question > below: > > > This PEP proposes to turn CI disposal into the following sequence (new > > steps are in bold): > > > > 1. Weakrefs to CI objects are cleared, and their callbacks called. At > > this point, the objects are still safe to use. > > > > 2. The finalizers of all CI objects are called. > > > > 3. **The CI is traversed again to determine if it is still isolated. > > If it is determined that at least one object in CI is now reachable > > from outside the CI, this collection is aborted and the whole CI > > is resurrected. Otherwise, proceed.** > > > > Not sure if my question is the same as Armin's here, but worth a try: by > saying "the CI is traversed again" do you mean the original objects from > the CI as discovered earlier, or is a new scan being done? What about a new > object entering the CI during step (2)? I.e. the original CI was A->B->A > but now one of the finalizers created some C such that B->C and C->A adding > it to the connected component?

It is the original CI which is traversed. If a new reference is introduced into the reference chain, the traversal in step 3 will decide to resurrect the CI. This is not necessarily a problem, since the next GC collection will try collecting again. > Reading your description in (3) strictly it says: in this case the > collection is aborted. This CI will be disposed next time collection is > run. Is this correct? Yup.

Thanks, this actually makes a lot of sense. It's strictly better than the current situation where objects with del are never collected. In the proposed scheme, the weird ones will be delayed and some really weird ones may never be collected, but the vast majority of del methods do no resurrection so usually it will just work.

This is a great proposal - killer new feature for 3.4 ;-)

Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130518/b103436a/attachment-0001.html>

More information about the Python-Dev mailing list