[#3006] mismatched quotation — "stevan apter" <apter@...>

ruby documentation uses a punctuation convention i've never seen

13 messages 2000/05/27

[ruby-talk:02985] Re: What our Python friends are up to.

From: jeremy@...
Date: 2000-05-25 14:33:41 UTC
List: ruby-talk #2985
Here are a few clarifications and explanations about current work
on Python 1.6.  There are changes -- some currently available in
the CVS tree and others planned for the near future -- that affect
the comparison with Ruby.

I hope you'll forgive my minimal familiarity with Ruby.  It looks
interesting, but I haven't had time for anything more than a cursory
look.

In article <E12u71B-0004yM-00@ev.netlab.co.jp>,
  matz@netlab.co.jp (Yukihiro Matsumoto) wrote:
> Here's the quote from my (yet unpublished) article.
>
>   On the Python newsgroup, questions/requests/complains like the
>   following have been repeated time to time.
>
>   * I dislike code structuring by indentation.

Of course, many Python programmers don't want this to be "solved." :-)

>   * Why Python has no "real" garbage collection?

Planned for 1.6.  Neil Schemenauer has working code for this.

>   * Why there are two distinct data types, list and tuple?

I think it's helpful to have a distinct type that is immutable.  This
can simplify reasoning about a program's behavior, e.g. in the face
of concurrency.

I take it that Ruby has only one sequence-like data type.  Is there
a mechanism to provide immutability?

>   * Separating types and classes are annoying.  Why all values are not
>     class instances?

You've got Python on this one.  I don't think this will be fixed
by Python 1.6, but certainly by Python 1.7.

>   * Why no method is available for numbers, tuples, strings?

Actually, strings do have methods.  I'm not sure how useful it
is for numbers and tuples to have methods.

>   * Explicit conversion between small integers and long integer are
>     annoying.

Yes.  So is the fact that 1/2 == 0 and not 0.5.

>   * Maintaining reference count in the extensions is tiresome and
>     error prone.

I believe some of the arguments in favor of Python's reference counting
are that it simplifies porting to new architectures and that it provides
immediate finalization with low complexity.  One problem you didn't
mention with reference counting is that it greatly increases locking
overhead on SMP machines.

What article are you working on?

Regards,
Jeremy



Sent via Deja.com http://www.deja.com/
Before you buy.

In This Thread