[Python-3000] PEP: Eliminate __del__
rhamph at gmail.com
Fri May 4 20:35:28 CEST 2007
On 5/4/07, Guido van Rossum <guido at python.org> wrote:
> On 5/4/07, Steven Bethard <steven.bethard at gmail.com> wrote:
> > On 5/4/07, Guido van Rossum <guido at python.org> wrote:
> > > Hm, a thought just occurred to me. Why not arrange for object.__new__
> > > to call [the moral equivalent of] weakref.cleanup(self,
> > > self.__class__.__del__), and get rid of the direct call to __del__
> > > from the destructor? (And the special-casing of objects with __del__
> > > in the GC module, of course.)
> > That seems like a good idea, though I'm still a little unclear as to
> > how far the AttrMap should be going to look like a real instance. As
> > it stands, you can only access items from the instance __dict__. That
> > means no methods, class attributes, etc.::
> Oh, you mean 'self' as passed to the callback is not the instance?
> That kills the whole idea (since the typical __del__ calls
> self.flush() or self.close()).
[..snip example using __dict__..]
> If it really has to be done this way, I think the whole PEP is doomed.
Any attempt that keeps the entire contents of __dict__ alive is
doomed. It's likely to contain a cycle back to the original object,
and avoiding that is the whole point of jumping through these hoops.
I've got a metaclass that moves explicitly marked attributes and
methods into a "core" object, allowing you to write code like this:
__coreattrs__ = ['_fd']
def __init__(self, path):
self._fd = os.open(path, ...)
# This method is written to be idempotent
if core._fd is not None:
core._fd = None
I've submitted it to the python cookbook, but I don't know how long
it'll take to get posted; it's a little on the long side at 163 lines.
The biggest limitation is you can't easily use super() in core
methods, although the proposed changes to super() would probably fix
Adam Olsen, aka Rhamphoryncus
More information about the Python-3000