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

Dave Cole djc at itga.com.au
Wed Nov 3 00:14:01 EST 1999


> * 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. The initialisation function of the Ruby dbm module
> starts off like this:
> 
> void
> Init_dbm()
> {
>     cDBM = rb_define_class("DBM", rb_cObject);
>     rb_include_module(cDBM, rb_mEnumerable);
> 
>     rb_define_singleton_method(cDBM, "open", fdbm_s_open, -1);
>     rb_define_singleton_method(cDBM, "new", fdbm_s_open, -1);
>     rb_define_method(cDBM, "close", fdbm_close, 0);
>     rb_define_method(cDBM, "[]", fdbm_fetch, 1);
>     rb_define_method(cDBM, "[]=", fdbm_store, 2);
>     rb_define_method(cDBM, "indexes",  fdbm_indexes, -1);
> 
> etc. There is no need to declare and initialise a type object
> or method table as in the Python version, which makes things
> somewhat more direct and easier to follow.

Couldn't you achieve the same thing in Python with an API that
allocated the PyTypeObject on the heap and returned a handle/pointer
to that.  It could also provide an internal tp_getattr which scanned
the method table you built up via method registration functions in the
same API.

- Dave




More information about the Python-list mailing list