does python have useless destructors?

[Roger Binns]

Duncan Booth wrote:
> "Roger Binns" <rogerb at rogerbinns.com> wrote in
> news:q3ipp1-4bp.ln1 at home.rogerbinns.com:
>
> > You have totally confused me now.  Ignoring special cases such as
> > cycles, Python destructs an object when there are no references left
> > to it, and in CPython that happens at the moment the last reference is
> > released. So in normal code the objects will go away as names
> > referencing them go out of scope.
>
> I wouldn't say that cycles are special cases exactly.

They are to the point I was trying to make, which is that objects
are freed when there are no references left in the CPython implementation.

The rest of your comment is missing my point.  I don't particularly
care about *when* an object is garbage collected, just that *is*
garbage collected at some point.

The whole problem that this thread is about is that Python has this
bizarre scheme that an object will be garbage collected *unless* you
add a __del__ method, at which point the docs imply you will be lucky
for garbage collection to *ever* happen on the object.

> No, Python guarantees that the object will (almost always) be destroyed.

The issue is the cases when it doesn't destroy objects.  That is the
whole point of this discussion and I refer you to the very first
message:

http://groups.google.com/groups?selm=slrnccetd9.gag.msoulier%40tigger.digitaltorque.ca

> Guaranteeing that all resources will be released at a specific time has
> implications for performance, and finalisers are actually pretty rare in
> practice, so the usual solution is to compromise.

It isn't a timing issue.  It is a "will it ever happen" issue.

Roger