Python 2.0

[Hisao Suzuki]

In article <000c01beb2e8$0b825440$af9e2299 at tim>,
"Tim Peters" <tim_one at email.msn.com> wrote:
| [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.

Certainly.  And many languages either give up them to
programmers entirely (---"Please make your own finalization
mechanism from scratch" from ???), or provide rather
insufficient ones (---"However, it is not a good idea to rely on
finalization for the timely freeing of resources." from Java
Programmers FAQ).

| > (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).

Surely the shutdown time is the most critical for the current
Python and it is the main reason why I wrote "though _not_
fully".  You might know that

in article <u36756gcoc.fsf at ares.sys1.ngo.okisoft.co.jp>,
I wrote:
< As for the issue of circular references, in my opinion, the
< future Python should use non-compacting GC at the end of the
< last thread and destroy the remained objects by invoking their
< __del__ methods --- it is THE time to destroy all the objects
< remained, so this is conceptually clean (thus very Pythonic :-),
< though it is the way of memory management used in the present
< Perl in fact...

It is only a casual idea and I am not sure what sort of
non-compacting garbage collector (or garbage detector, in this
case?) is implementable and acceptable as part of Python system.

For example, I have once thought what if each instance has two
additional pointers, which make up the object list, i.e. oblist.
(PyInstance_New and others will need modifying then.)  After
folding up the stack(s), Python checks the referred instances
from, say sys.modules (see my article
<u31zfszath.fsf at ares.sys1.ngo.okisoft.co.jp> for a half-baked,
or rather a-tenth-baked quick-and-incomplete prototype), detects
possible circular references from the oblist, invokes their
__del__s first and then shuts down the same way as the current
Python does.  Well, it may correct some faults, but I know it is
neither perfect nor efficient anyway.

--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao            suzuki611 at okisoft.co.jp, suzuki at acm.org.