suzuki611 at okisoft.co.jp
Thu Jun 10 02:43:07 CEST 1999
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.
More information about the Python-list