[Python-Dev] PEP 442: Safe object finalization

[Eli Bendersky]

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>