Hi,

following your request, I have read the comparsion again. It was not
wrong (except one case), but perhaps could be improved nevertheless.

Here are my comments:

> Python deals with problem areas as similar as Ruby does. Now, let's compare 
> Python with Ruby: 
> 
> - incomplete OOP 

That is the only point, IMHO, that is wrong. So I would not second
that. Python has complete OOP, but ... see below:

>   o No encapsulation 

I assume you mean data hiding in the sense, that outworld may not be
able to access the data??? If so, I mean that this no feature of
OOP!!! Truely spoken, that is also not the case in Ruby. Everybody can
simply extend the class/object during runtime, to introduce a method,
that can access the instance variables too.

>   o Some data (numerical, list, dictionary, string, etc.) are not class 
>     instances. 

Again, that is no feature of OOP. That does not make Python featuring
incomplete OOP. But it makes Python a incomplete *OOL* ;-)))

>   o Extension modules in C don't realize class instances. 

And this too, IMHO is not a a sign of incomlete OOP! It is only a
pitty. I remember I have had a Smalltalk version (perhaps Smalltalk V
(DOS) }:-| ) that also didn't enable you to write classes in C. Only
in Smalltalk. But until today, I think it was *complete* OOP
nevertheless. :-)

>   o Tiresome self. are required when each access to instance variable. 

Sorry for playing the devils advocate here. But we really should pay
much attention to such comparsions. If we don't stay on firm ground,
we will sink.

Again that tiresome self, is not a sign of complete OOP. After all, I
think we had seen nothing, that proves the incomplete OOP of
Python. Better to remove that point altogether. Let only remain the
differences and advantages between Ruby's OOP and Python's one.

> - Functions are first class object (Of cource, we know it is not weak) 

Sometimes I wish, Ruby would also feature this. But okay, I can live
without it.

> - del, len, etc. are not object-oriented. (There are __len__, etc. but ...) 
> - Ugly method calling for superclass 
> - No class method (module functions alternate it) 
> - No way to automatically convert between long integer and small integer. 

Better to reformulate this? Better to say something like: User has to
obey internal representation in Python. If a integer becomes too
'large' user has to convert it into a large one.

> - Because there is no genuine GC, 
> 
>   o Memory leak occur sometimes because of refcounting. 
>   o Writing extension modules is bothersome 
>     (INCREF, DECREF; some betterments in 1.5?) 

Very important point!!!

> - Tuple and list has overlap functionally (not serious) 
> - Function objects are accepted as arguments, but iterators are more elegant. 

Not everybody agrees that (but I do ;-). But we should explain, what
is meant with iterators. I don't like that term too much. Iterators
for me are methods, that iterates over every element in a collection
and do something with them (perhaps call another method?). 

Another definition says, iterators are objects, that deliver one
element after the other contained in a certain collection (the C++ way).

So, I mean, Array#collect or Array#find, are iterators. But
e.g. File#open is not an iterator, but it can also receive a
block, to do something.

BTW: That is also a reason I don't like the 'iterator?' keyword to
much! I would prefer an alias like 'has_block?' or something like that.

> - After all, declarations are featured (global) 
> - Often slower than Ruby (may be improved?) 

Nothing to say here.

After all, I mean it could be better to explain where Ruby has
advantages over Python, instead of explaining where Python would be
*weak* comparing to Ruby (psychological: Don't tell me where I am
worse, tell me where you are better than me ;-)))


Here is my trial (beeing too verbose as I ever am ... ;-):

Python deals with problem areas as similar as Ruby does. But we Ruby
users mean, that Ruby has some big advantages over Python in some
points, other points are only different. But see yourself:

- Ruby is an complete OOL. That mean all in Ruby is an object. Not in
  the sense of Python or Perl. But in the sense of Smalltalk. The
  number 1, e.g. is an instance of class Fixnum.

- Ruby's OO is carefully designed to be both complete and open for
  improvements. E.g. Ruby has the capability to add methods to a
  class, or even an instance during runtime. That means, if it is
  necessary, an instance of a certain class *could* behave different
  from other instances of the same class.

- Ruby features single inheritance only, *on purpose*. But Ruby knows
  the concept of modules (called Categories in Objective-C). Modules
  are collections of methods. Every class can import an module and so
  becomes all it methods for free. Some of us think, that this is a
  much clearer way than multiple inheritance, which is complex, and
  not used very often compared with single inheritance (don't count
  C++ here, as it has often no other choice due to strong type
  checking!).

- Ruby features true closures (much nicer than Python's lambda's).

- A method in Ruby cannot be separated from its class and passed into
  another one. The compiled representation is too much bound to the
  class where it was compiled for (performance reasons). But you can
  use closures to achieve the same goal.

- Ruby features block in its syntax (code surrounded by '{' ... '}' or
  'do' ... 'end'). These blocks can be passed to methods, or converted
  into closures.

- C extensions define methods and/or classes for Ruby. You can also
  use a C coded class as parent of another one coded in Ruby (no
  type/class clash as in Python).

- Ruby features a true mark-and-sweep garbage collector. It works with
  all ruby objects. You have not to use any INCREF or DECREF. It is
  better for your health. ;-)

- Writing C extensions in Ruby is easier than in Python. Partly
  because of the garbage collector, partly of the fine extension API.

- Integers in Ruby can (and should) be used without count on their's
  internal representation. There *are* small integers (instances of
  class Fixnum) and large integers (Bignum) but you have not to take
  sorrow, which one is used currently. If the value is small enough, a
  integer is a Fixnum, otherwise a Bignum. Conversion takes place
  automatically. You simply use them!!!

- Ruby doesn't need declarations at all. It use some naming
  conventions to indicate, what the scope of a variable is. For
  example means: '@var' an instance variable, '$var' a global variable
  and simple 'var' a local one. So it is also not necessary to use
  tiresome 'self.' prepended to every instance member.

- You can use any Python class within Ruby nearly seemingless. There
  is a C extension, that provides that feature ;-)))


I have, for sure, forgot some point worth to mention here, but perhaps
you can find some valuable in between all these verbosity above ;-)

\cle