does python have useless destructors?
donn at u.washington.edu
Tue Jun 15 20:26:33 CEST 2004
In article <m3fz8xozi1.fsf at pc150.maths.bris.ac.uk>,
Michael Hudson <mwh at python.net> wrote:
> Manlio Perillo <NOmanlio_perilloSPAM at libero.it> 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 u.washington.edu
More information about the Python-list