>> I don't think it makes a lot of sense to put an __del__ method on a
>> Persistent object.
> I just read in "cPersistence.c:ghostify":
> /* We remove the reference to the just ghosted object that the ring
> * holds. Note that the dictionary of oids->objects has an uncounted
> * reference, so if the ring's reference was the only one, this frees
> * the ghost object. Note further that the object's dealloc knows to
> * inform the dictionary that it is going away.
> This means: *all* persistent objects have a special "dealloc"
Most Python objects do (persistent or not), pointed to by the type's
tp_dealloc slot, or inherited from a base type's tp_dealloc. Having a
tp_dealloc function isn't the same as having a __del__ method, though:
tp_dealloc is part of the system implementation, while __del__ is arbitrary
user-defined Python code. It's required that the presence or absence of
tp_dealloc not make any difference to cyclic gc, and gc doesn't even check
for their existence. Since tp_dealloc implementations are "part of the
system", they can (and do) impose restrictions on their authors that aren't
imposed on authors of Python __del__ methods.
> Hope, this "dealloc" function plays well with the cyclic garbage
If a case is found where it doesn't, it's a bug in the persistent tp_dealloc
It was hard to get cyclic gc to work with the cache, in large part because
of the "dictionary of oids->objects [with] uncounted reference[s]" (Python's
cyclic gc is based on having truthful refcounts), and we did hit plenty of
bugs in the process. We don't know of any that remain. Doesn't mean there
aren't any remaining, but does mean a lot of brain cells already got burned
trying to ensure that the persistent dealloc functions play nice with cyclic
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -