[Python-3000] Removing __del__
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