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

[Yukihiro Matsumoto]

Guido van Rossum <guido at cnri.reston.va.us> writes:

|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!)

It's using longjmp.  We haven't met longjmp's nasty portability
problems yet, for 6 years.

|> 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???

It's part of the method attribute.  C functions are registered with
the number of arguments they accept.

|> * 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.

Surely.
							matz.