Python 2.0

[Hisao Suzuki]

In article <87so8bnsd6.fsf at ev.netlab.co.jp>,
Yukihiro Matsumoto <matz at netlab.co.jp> wrote:
> |Perhaps it is safe to say that destructors with real GC are more
> |error prone.  (The present Python is safer in this respect!)
> Safer than Java, probably.
> 
> Ruby garantees (well, trying to garantee) that ALL finalizers will be
> called before process termination, so that Ruby is as safe as Python,
> at least theoretically.

This sounds a sort of advocacy of your Ruby...

Any way, the idea of destructors with "real" GC is a conceptual
contradiction.  Such GC emulates infinite memories and objects
are never destroyed *virtually*.  Thus the destructors should
never be invoked with real GC.

Certainly you may make your GC routine retrieve not only
memories but also various resources (such as file descriptors),
but it is highly error prone to make the routine invoke
ARBITRARY destructors specified by arbitrary users.  Such
invocation may introduce serious indeterminism or
unpredictability into the behavior of user's program.

# Well, in this respect, Ruby might be more indeterministic
# than Python.

Even if Python has "real" GC someday, IMHO, the GC should be
used only to imitate infinite resources.  For the sake of
conceptual simplicity, the future Python should still use
reference counting both to invoke __del__ methods and to free
storages; the GC routine should be used as the last resort.

# Or, deprecate both __del__ methods and reference counting?
# --- it will result in another language than Python.

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