Python 2.0

[Yukihiro Matsumoto]

Hisao Suzuki <suzuki611 at okisoft.co.jp> writes:

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

Well, maybe..

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

I thought GC is the way to reclaim the unreferenced objects.  I think
it is not directly related to infinite memory space, even though you
can choose it as the conceptial model for 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.

Do you mean finalizers with real GC (as in Java) is the source of
indeterminism?  Maybe you're right.

BTW, did I say Ruby can invoke arbitrary destructors specified by
arbitrary users?  It can't.

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

I don't think it is.  But, well, I have to confess Ruby is unstable
than Python yet.

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

I agree with it.  I wouldn't claim to remove ref counting from Python.
Combination of ref counting and real GC may be the best for Python,
accomplishes both compatibility and reliability.

						matz.