Python 2.0

[Hisao Suzuki]

In article <87pv384koy.fsf at ev.netlab.co.jp>,
Yukihiro Matsumoto <matz at netlab.co.jp> wrote:
| It's because conservative-ness of Ruby's GC, you know.  There should
| be no portability problem with Graham's proposal, mark and sweep GC
| with ref counting, unless implementor try to make it conservative.

and also wrote:

| I claimed in summary:
|   * I don't like mere ref counting; it cannot reclaim cyclic data, and
|     easy to forget INCREF/DECREF.
|   * Many among Python users misunderstood about real GC.
|     (slow, hangs, non portable, etc.)
|   * ref counting with GC may be good for Python 2.0.
| Did I do any advocacy on Ruby?  I was trying constructive discussion.

Well, you have experience of some non-portable conservative
garbage collector on your Ruby, while advocating potential,
portable one for Python, don't you?

Moreover, I am afraid that your experience and argument might
have nothing to do with general, complex finalization.  Once
thinking of better storage management for Python _seriously_,
this will be a real problem.  (I pointed out this matter for
several times recently, you know.)

A very common discussion on GC has been already given.  I hope
you read Doc/ext/ext.tex or `the Extending and Embedding the
Python Interpreter'.  (Judging from your referring to
INCREF/DECREF, you might have read it...)

I'm sorry to say, but your argument is too trivial (or rather
naive) to consider as a constructive discussion.  Having almost
nothing to do with real problems on Python, your referrings to
your Ruby (surely in triumphant tones) sound evangelic.  I'd be
glad if you would present a non-trivial viewpoint or propose a
practical solution _relevant_ to Python actually.

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