Comparison between Python and "Ruby"

[Martijn Faassen]

Ian Clarke <I.Clarke at strs.co.uk> wrote:
[quoted from the Ruby documention]
> Problems with Python are:

> * incomplete OOP 

This is vague without more elaboration. It's either the class/type 
difference they refer to later, or perhaps the lack of advanced
data hiding constructs (which I must say I don't miss).

Can't be interfaces, thought they'd be nice; I don't think they're 
part of the Genuine OOP (tm) concept.

> * Some data (numerical, list, dictionary, string, etc.) are not
> genuine   
>   object. 

They are real objects, they're just not real class instantiations. But they
behave like objects. The disadvantage is of course that they don't have classes
you can derive your own stuff from. In practice you don't do this a lot,
and in practice, there are classes like UserDict and UserList to take
care of this problem.

Still, this distinction doesn't feel clear, and it is something that people
want to address for Python 2.0.

> * Extension modules in C don't realize genuine objects. 

For certain values of the word 'object', this is true. :) The classless
objects (they have 'types' instead) are implemented in C, while the 
classy objects are generally implemented in Python. There are extension
systems muddle this difference, though. Personally I haven't worked 
with them, though I know Zope uses ExtensionClasses.

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

Opinions differ on this one. The 'self.' prefix makes it very clear you
are dealing with a class variable. It also makes it clear that this is
actually exactly the same as an 'other.' prefix; the symmetry here is nice.

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

If it's not a weakness, what's the problem? :)

>  del, len, etc. are not Object-Oriented. (There are __len__, etc. but
> ...) 

There's a good reason for the 'del'; it removes a variable from 
a namespace. Conceptually it works on the reference, not on the thing that
the reference refers to. Sort of like '=' for assignment, and we don't
complain about that one either. This is a FAQ.

len is a FAQ too; the idea is that the len() function is generic. Also that
it can be applied on object that don't have any methods.
But I'd agree one could argue about this one.

> * Ugly method calling for superclass 

Agreed. Though fairly simple and flexible. But something nicer (what?) would
be nicer.

> * No class method (module functions alternate it)

Python's strong namespace support and module functions almost make class 
methods unnecessary. (although this is helped by the fact that 'private'
data members (__foo) are not so commonly used in Python). Anyway, they'd
be nice to have, but it's certainly not terrible they're not there.
 
> * No way to automatically convert between long integer and small
> integer. 

I'll leave this to someone else. Is this a problem? A feature?

> * Because there is no genuine GC, memory leak occur often 

I'd say 'often' is an exaggaration, but of course GC is on lots of people's
wishlist for Python, so no argument here; this is a problem.

> * Writing extension modules is bothersome (some betterments in 1.5) 

People more experienced with this can comment on this. Using SWIG certainly 
isn't very difficult, though..

> * Tuple and list has overlap functionally (not serious) 

No, not serious. The distinction is sometimes useful.

> * Function objects are accepted as arguments, but iterators are more
> elegant. 

You can implement iterators in Python, though?
Better core level iterator support would be nice for Python 2.0, though 
(for instance for loops could use them).

> * After all, declarations are featured (global) 

Only if you want to change a global variable (which you're not supposed to
have lots of anyway, usually). If you want to use one it's no problem. But
agreed that the whole 'global' business is tricky.

> * Slower than Ruby (may be improved?) 

Quite possible' don't know. Benchmarks..

> I am still trying to download a copy of Ruby to look at it myself,
> however do people think these comments are justified?

Most of them have a point, but the problems caused by these things are
generally not big. Some of these problems are seen by others as advantages.
All in all, if this is the worst list of problems one can come up with
for Python..it could've done far worse. :)

Regards,

Martijn 
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?