Python equivalent of C++'s virtual destructors?

[Alex Martelli]

"Erik Max Francis" <max at alcyone.com> wrote in message
news:39871A7E.4DC95AF2 at alcyone.com...
> Alex Martelli wrote:
>
> > I believe this restriction is meant to apply to 99+% of the cases, the
> > odd-case out being exactly this one: a derived class's __del__ needing
> > to call the parents'.
>
> Thanks.  I had a feeling that that was the right thing to do, but it
> wasn't clear to me.
>
> Actually, I sort of like having all calls to __init__ or __del__ for
> base classes be explicit.  It eliminates any question of what's going
> on.

I will confess that this is one little thing I can't really get
used to; one of the few gotcha's (for me) of the "explicit is better
than implicit" paradigm.  I've been burned a few times over the
months; failing to call a parent's __init__ generally becomes quite
obvious after moderate testing, but failing to call a parent's
__del__ is often (for me, at least) a subtler "bug just waiting to
happen".  I'm quite happy with most all applications in Python of
the 'explicitness preference' (particularly the self. being
explicit: just thinking of C++ and Java having implicit this->,
and then people systematically calling member variables m_foo
or itsBar, is quite funny, after all...!-).  But I'd love it if
__del__ was one exception, requiring explicitness to _stop_ the
parents' __del__ from being called!-).  Oh well, I'll survive...


Alex