[Python-3000] Removing __del__

Ron Adam rrr at ronadam.com
Tue Sep 26 16:45:03 CEST 2006

Giovanni Bajo wrote:

> Since we are discussing Py3k here, I believe it is the right time to revive
> this discussion. The __close__ proposal I'm backing (sumed up in this mail:
> http://mail.python.org/pipermail/python-3000/2006-September/003892.html) is
> pretty similar to how Guido was proposing to modify __del__. If there are
> technical grounds for this (and my opinion does not matter much, but Guido
> was proposing the same thing, which kinds of gives me hope in this regard),
> I believe it would be a far superior solution for the problem of implicit
> finalization in the presence of CT in Py3k.
> I think the idea is that, if you make sure that a __close__ method is called
> exactly once (and before __dict__ is reclaimed), it really does not matter
> much in which order you call __close__ methods within the CT. I mean, it
> *might* matter for already-written in-the-wild __del__ methods of course,
> but it sounds a *very* reasonable constraint for Py3k's __close__ methods. I
> would like to see real-world examples where calling __close__ in random
> order break things.

How about...?  (This isn't an area I'm real familiar with.)

Replace __del__ with:

    a __final__ method and a __finalized__ flag.  (or other equivalent names)

    Insist on explicit finalizing by raising an exception if an objects
    __finalize__ flag is still False when it looses it's last reference.

Would this be difficult to do in a timely way so the traceback is meaningful?

Would this avoid the problems being discussed with both __del__ and weak refs?


More information about the Python-3000 mailing list