Python 2.0

[Tim Peters]

[Hisao Suzuki]
> ...
> It would be an issue of distributed garbage collection.  And it
> is a difficulty for automatic GC with finalization.

Yes, there are real problems here, and Python certainly isn't the first to
face them.

> In addition, perhaps we should also take a (close) look at
> ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/guardians.ps.gz
>
> It summarizes other (or rather more general) issues to consider
> in the design of a finalization mechanism (and presents one
> solution for Scheme---actually it is adapted by gnu guile).  I'd
> think anyone who is planning improvements on Python's storage
> management has to _notice_ what are summarized there first.

Excellent suggestion; excellent paper, too <wink>.

> (The solution is another story.  It is not so obvious for
> Python.)
>
> # Certainly the current reference counting system of Python
> # reduces the issues to fairly (though _not_ fully) tolerable
> # ones...

It automatically deals with the order-of-finalization problem in a correct
way, by following a topological sort of the "references" graph.  Which says
almost nothing, since that's *natural* for RC.  In return it can't deal with
cycles at all, and indeed it's still easy to write __del__ methods that
trigger mysterious exceptions at system shutdown time, when Python *does*
clean up *some* kinds of cyclic trash (namely the cycles the interpreter
itself creates for its own nefarious purposes).

All in all, though, the lack of "real GC" has never stopped me from doing
anything in Python, nor the lack of "real RC" from doing anything in any
GC'd language.  The lack of "any C" in C <wink> has stopped me often in that
language, though.

the-ocean-holds-many-mysteries-but-we-live-longer-than-fish-ly y'rs  - tim