What's TOTALLY COMPELLING about Ruby over Python?

Andrew Dalke adalke at mindspring.com
Fri Aug 22 07:18:24 CEST 2003


David Garamond:
> Ah, but this improves readability for me. Some people might also argue
> that all those underscores in Python code reduces readability. And how
> many threads are lost for people complaining about having to write
> 'self.foo' all the time? ;-)

What if you had your editor expand '@' into 'self.'?  (Not something
I would do.)

And how many Ruby threads are lost for people complaining about
having to write 'end' <wink>.

> >  As a result, I wonder how well Ruby works as an embedded language.
>
> Not very badly, I think. mod_ruby, eruby, pl-ruby, jruby, ... Though the
> last one is nowhere near usable as Jython right now.

When I looked at Ruby a few years ago, I had concerns about
how its thread system (a platform independent/non-native) system
would interact with, say, POSIX threads or with an in-proc COM
server.  I never found out the answer for that.

I also had concerns with its non-ref-count based garbage collection
for C extensions, because the C/Fortran libraries I use most often
for chemistry only pass opaque integer tokens around, and not raw
pointers, so there's no way for Ruby to know when to dealloc
things or what the proper deallocation order would be.

> And what's not consistent about :: for namespace separator, $ for global
> vars, @ for class vars, and so on?

Python gets away with doing the :: and @ with just a name and
a period.

  'x' is local or global
  'x.y' is the 'y' thingy in 'x', and 'x' could be a module, a class,
    or an instance

So the inconsistency, from a Python view, is that the "get something
from something else" is written in different ways depending on
the source of the data.

> The current
> implementation of Ruby (Ruby 1.x) is admittedly not very fast, but it's
> already much faster & efficient than Python for some things (like
> creating and destroying objects/classes).

How is that tested?  I hear that new-style classes for Python are
faster than old ones.  Still, I decided to test out object creation
on a machine which has an older version of Python and of Ruby
installed.

%python -V
Python 2.2.2
%ruby --version
ruby 1.6.5 (2001-09-08) [i386-freebsd4.4]
%
%cat t.py
class Qwerty:
  def __init__(self, name):
    self.name = name

for i in xrange(1000000):
  Qwerty("shrdlu")

%cat t.rb
class Qwerty
  def initialize(name)
    @name = name
  end
end

for i in 0...1000000
  Qwerty.new("shrdlu")
end
%time python t.py
3.303u 0.000s 0:03.42 96.4%     774+1008k 0+0io 0pf+0w
%time ruby t.rb
3.466u 0.185s 0:04.25 85.6%     5+889k 0+0io 0pf+0w
%

I deliberately chose Python code known to be slow.
Here's the faster version

%cat t.py
class Qwerty:
  def __init__(self, name):
    self.name = name

def main():
  for i in xrange(1000000):
    Qwerty("shrdlu")

main()
%time python t.py
2.929u 0.000s 0:03.36 86.9%     773+1008k 0+0io 0pf+0w
%

Faster because 'i' is in local namespace (simple offset
lookup in the list of local variables) vs. global namespace
(dictionary lookup).  Deliberately chosen because I don't
know if Ruby has similar differences.

                    Andrew
                    dalke at dalkescientific.com






More information about the Python-list mailing list