A Comparison of Python and Ruby Extension Interfaces (Re: Comparison between Python and "Ruby")

[Guido van Rossum]

Greg Ewing <greg.ewing at compaq.com> writes:

> * The names of the Ruby interface routines are often
> shorter than the equivalent Python ones.

Python used to have short names too, and in fact the current naming
scheme was intruduced with great reluctance.  Unfortunately the
realities of embedding Python in other apps required the current
longer names, to avoid name clashes between Python macros, types and
externals and ditto defined by the embedding app.  Extension modules
wrapping large existing libraries also ran into this.

> * Ruby seems to be able to raise exceptions without
> having to explicitly propagate them back out of routines,
> which eliminates a lot of result testing and returning of
> -1's and None's that goes on in Python extension code.

Does it use longjmp to do this?  Or is it written in C++ and using C++
exceptions?  Note that longjmp is a frequent cause of nasty
portability problems (e.g. recently a bug reported on FreeBSD when
combining threads and readline was discovered to be caused by a bug in
the longjmp implementation).

Or perhaps it has macros containing return statements?  (Yuck!)

> Some other observations, in no particular order:
> 
> * In Ruby, routines with a fixed number of arguments can
> be defined so that they are received as separate C
> arguments instead of a vector, e.g.
> 
> static VALUE
> fdbm_store(obj, keystr, valstr)
>     VALUE obj, keystr, valstr;
> 
> This doesn't actually save much code, however, since you
> still have to test and convert each argument.

How does Ruby know how many arguments the C code has???

> * Ruby's method of representing an extension type is a
> whisker more complicated. Instead of allocating a single
> object, you have to create an object of type DATA, which
> contains a pointer to a class and a pointer to a C
> structure.
> 
> * The mechanism for associating methods with object types
> is somewhat simpler in Ruby. In Python, some methods live
> in slots in the type object, while others live in a method
> table or are somehow otherwise accessed through the getattr
> method. In Ruby, all methods, including the ones for built
> in operations, are attached to the object's class, which seems
> to play the role of both the Python type object and method
> table.

I agree that this would be a desirable design for a future Python
implementation.

--Guido van Rossum (home page: http://www.python.org/~guido/)