does python have useless destructors?

Donn Cave donn at
Tue Jun 15 20:26:33 CEST 2004

In article <m3fz8xozi1.fsf at>,
 Michael Hudson <mwh at> wrote:
> Manlio Perillo <NOmanlio_perilloSPAM at> writes:
> > Since __del__ isn't really 'useful', *maybe* a better solution is to
> > add another special method for classes, ad example a __finalize__
> > method.
> Yes!  I'm not sure __finalize__ is really the best name, but that's
> for another day.

Couldn't the name be __del__?  Given the opportunity to have
both, and the assurance that __finalize__ will be called and
__del__ might not, what functionality would you leave in __del__?

> I would urge everyone participating in this thread to read PEP 310,
> the email conversation linked therein and (optional) *understand* it.

It seems to be superficially similar to finalization, but so
constrained that it's architecturally inconsequential - I mean,
it's by definition interchangeable with a try/finally construct,
so there isn't any potential code architecture where you can say
`couldn't do this without with'.

I guess there isn't much point in proposing improvements for
finalization and __del__, as long as there's a commitment to
support Python on a platform without support for finalization
like Java.  But never one to be deterred by pointlessness,
suppose __finalize__ were a flag, instead of a method.  It
has two functions:  1.  declare that the object's __del__
method should be called when it's logically unreferenced -
either no references, or only referenced as part of a cycle
or traceback.  2.  Serve as the extra reference count that's
needed for this, so __del__ will only be called once regardless
of further reference decrements, cycle analysis etc.  Default
would be no __finalize__, but it should probably be added to
some class/types, e.g., fileobject.

   Donn Cave, donn at

More information about the Python-list mailing list