Python 2.0

Yukihiro Matsumoto matz at netlab.co.jp
Mon Jun 7 07:57:17 CEST 1999


Hisao Suzuki <suzuki611 at okisoft.co.jp> writes:

|In article <7j90va$6lk$1 at cronkite.cc.uga.edu>,
|graham at sloth.math.uga.edu (Graham Matthews) wrote:
|> I am completely confused by this statement. The two people that have
|> been advocating GC the hardest are myself and the author of Ruby. Since
|> Ruby has GC the author has clearly implemented a collector. ...
|
|Regrettably, I'd have to say that Ruby is (was?) suffering from
|its insufficient portability.  Once I have used a certain i860
|SVR4 box.  On that box, Ruby did not run but dumped immediately
|with its twiddling the machine stack, while Python ran perfectly
|with no difficulty.  As far as I know, the collector of Ruby has
|not changed so much since then.

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.

I've never claimed Ruby is as portable as Python.  Definitely Python
runs on the machines where Ruby cannot run, say on small devices.

|(I have before told this to the author of Ruby on a Japanese
|Pythoneers' mailing-list against his advocacy of Ruby, and now
|he appeared here again with just the same opinion before...)

What opinion of mine do you have in mind?

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.

						matz.




More information about the Python-list mailing list