Final garbage collection?

[Jerome Quelin]

wware at world.std.com (Will Ware) wrote:
>That's correct. Garbage collection in Python is accomplished by
>reference counting. When a gets a pointer to b, b's reference count
>is incremented, and vice versa.
I know that, but I expected Python to do a final check-up when exiting,
just like Perl does. I know this is a Python newsgroup, but here is a sample
snippet of Perl code:

$ cat test.pl
#!/usr/bin/perl
package Test;
sub new {
    my $self = bless ({}, 'Test');
    $self->{name} = $_[1];
    return $self;
}
sub DESTROY {
    my $self = shift;
    print "Ouch! ($self->{name})\n";
}
package main;
$a = new Test('a');
$b = new Test('b');
$c = new Test('c');
$a->{cross_ref} = $b;
$b->{cross_ref} = $a;
$ ./test.pl
Ouch! (c)
Ouch! (b)
Ouch! (a)
$

Perl implement its garbage collection by counting references too. And circular
references aren't collected since their reference count does not reach zero,
just like in Python.
But, (and the following is taken from perl documentation -man perlobj):
       When an interpreter thread finally shuts down (usually
       when your program exits), then a rather costly but
       complete mark-and-sweep style of garbage collection is
       performed, and everything allocated by that thread gets
       destroyed.  This is essential to support Perl as an
       embedded or a multithreadable language.

I was wondering why Python does not implement such a mechanism, that
seems to me a Good Thing (tm), because _in final_, every object _is_
destroyed, either if their reference count is nul or not, since the memory is
reclaimed by the system.

Sorry for the above Perl code for Python integrists.

Jerome
--
jerome.quelin at insalien.org