Python 2.0

[Yukihiro Matsumoto]

"Vadim Chugunov" <chega_ at yahoo.com> writes:

|> I don't get it.  There's no relation between destructors and real
|> garbage collection.  For example, Java uses destructors called
|> finalizers, even though most Java VM use real GC.
|
|Right, but java finalizers will not be called till the moment the memory is
|collected.
|Depending on the GC configuration and the program's memory consumption this
|may be quite a while.

|> I hate ref counting.  It is memory-leak prone, does not reclaim cyclic
|> data without explicit cycle-cut.  I know, by ref counting, object is
|> recycled as soon as it looses last reference to it, but relying on
|> that behavior is error prone, I think.
|
|Can you explain exactly why is it more error prone?
|If something can be done automatically, without writing explicit
|deallocation code,
|why can't we let it be that way?

Well, the reasons why ref counting is more error prone are:

  * ref counting never reclaim cyclic references, resulting memory
    leak.

  * extension module writers are easy to forget to put INCREF(),
    DECREF() properly, resulting memory problems (leak or crash).

These two never be caused by real GC.  From my viewpoint (of cource
biased), avoiding these is more important than predictability.

|OK, I'll try to propose something constructive. Maybe we need an object
|protocol, that would enumerate
|all references held by an object ?  Writing a portable GC would be then much
|easier.

Some languages use both.  Ref counting for usual basis, real GC for
full clean up.  How about adding real GC to Python 2.0, co-working
with ref counting?
						matz.