Python 2.0

[Yukihiro Matsumoto]

Hi.

Paul Prescod <paul at prescod.net> writes:

|> >As many people have noted before, you would not be able to use
|> >destructors to free up resources like memory or file descriptors.
|> 
|> which, as I understand, means destructors can not be used with real
|> GC.  That's just not true.
|
|Is there a language with real GC where destructors are called as
|predictably as they are in Python?

I said nothing about the destructor invocation predictability.

I don't understand and really interested in why you guys require
to predict destructor invocation so much, but it's another story.

|> >From my experience with Scheme and Ruby, both with real GC, the real
|> GC is mostly very fast.  
|
|Speed wasn't my concern. I asked about references in C code. Do we use
|PyObject **s instead of PyObject *s now?

Sorry, I don't understand.  Do we have to use PyObject **s instead of
PyObject *s, if we choose real GC?

|> Do you really mean Python the object-oriented programming language
|> rarely treat complicated data structures?  
|
|No, I said that Python is optimized for basic users, not for the experts.
|The experts can figure out how to work around problems. The beginning
|users cannot. "I'm opening all of the files in a directory in a loop and
|in large directories I get out of file handle errors."

First, it's not the straight result from real GC.  For exapmle, Ruby
uses real GC, and starts GC automatically on that situation.  No
problem arise.  It's totally a implementation matter.

Second, do you think that optimization for basic users compensates the
risk of potential memory leak, by cyclic structures or missing DECREF
in extension modules?  Do you mean it's easy for experts to find
cyclic structure and cut their reference to destruct?  For me, it's
not.  I hate that.  Is this because I'm not a Python expert?

						matz.