does python have useless destructors?

[Isaac To]

>>>>> "Marcin" == Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> writes:

    Marcin> On Mon, 14 Jun 2004 00:00:39 -0700, David Turner wrote:
    >> The D programming language somehow contrives to have both garbage
    >> collection and working destructors.  So why can't Python?

    Marcin> What happens in D when you make a pointer to a local variable,
    Marcin> the variable goes out of scope, and you use the pointer?

    Marcin> Undefined behavior? If so, it's unacceptable for Python.

After reading some docs of D, I find no reference to the behaviour that
Turner talked about.  There is a way in which one can make sure memory is
deallocated when a function exits, which uses the alloca C function.  Such
objects *must* not have destructor.  It is rather obvious what the run-time
would do: simply allocate them on stack using the GNU C alloca function, and
forget them completely.  When the function returns, the stack pointer
manipulation will get rid of the object.  It is easy for these objects to
work with the implemented copy collector of D: just scan the stack as well
when doing copy-collect.  Since they have no destructor, there is no
consequence of destruction of such objects at all during such stack wind-up,
other than freeing up some memory which can happen during the next GC run.

There is some mentions about reference counting.  But those must be
implemented by the programmer himself.  I.e., the programmer must allocate
fields himself to do reference counting, and do the increment and decrement
himself.  The D runtime does no reference counting.  And the program would
be buggy (e.g., call destructor too early even when a reference to it is
still there) if the programmer miss an AddRef or Release somewhere.  Indeed,
from the docs of D about the "benefit of GC", it is quite obvious that D
would do anything to avoid having to do reference counting in the runtime.
I'm wondering whether Turner makes the behaviour all up.

Regards,
Isaac.