Python 2.0

[Blake Winton]

On 10 Jun 1999 09:43:07 +0900, Hisao Suzuki <suzuki611 at okisoft.co.jp> wrote:
>In article <87pv384koy.fsf at ev.netlab.co.jp>,
>Yukihiro Matsumoto <matz at netlab.co.jp> 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.
>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.

I think this is a little harsh.  I've been reading this entire thread
(No, I don't know why), and Matz has seemed to me to be remarkably
restrained in his evangelical attempts.  Whenever he mentions Ruby, he
makes the disclaimer that it's not particularly portable, and only seems
to use it as a proof-of-concept, or demonstration that he has some skill
in writing GCs.

Ref counting with GC sounds to me like a good idea for Python 2.0, as it
will eliminate a class of memory leaks that Python can currently fall
prey to.  As long as you don't move stuff around in memory, and only
collect things where all the refcounts are accounted for, and can't be
reached, you should be safe.  Granted, this means that the people
writing the extensions will have to be careful to INCREF/DECREF where
they're supposed to, but I don't see that as a bad thing since they
should already be careful about that sort of stuff.

Later,
Blake.

-- 
One Will.  One Dream.  One Truth.  One Destiny.  One Love.