[Python-3000] Ctypes as cross-interpreter C calling interface

[Guido van Rossum]

On 8/14/06, Jean-Paul Calderone <exarkun at divmod.com> wrote:
> On Mon, 14 Aug 2006 09:09:49 -0700, Guido van Rossum <guido at python.org> wrote:
> >On 8/14/06, Jean-Paul Calderone <exarkun at divmod.com> wrote:
> >>This is a joke, right?
> >Because it's a good idea to have to write separate wrappers
> >around every useful library for each dynamic languague separately?
>
> If a project has done this successfully, I don't think I've seen it.  Can
> you point out some examples where this has been accomplished in a useful
> form?  The nearest thing I can think of is SWIG, which is basically a
> failure.

SWIG is not my favorite (msotly because I don't like C++ much) but
it's used very effectively here at Google (for example); I wouldn't
dream of calling it a failure.

I also consider .NET's CLR a success, based on the testimony of Jim
Hugunin (who must be Microsoft's most reluctant employee :).

And I see the JVM as a successful case too -- Jython can link to
anything written in Java or compiled to JVM bytecode, and so can other
languages that use JVM introspection the same way as Jython (I hear
there's  Ruby analogue).

The major difference between all these examples and ctypes is that
ctypes has no way of introspecting the wrapped library; you have to
repeat everything you know about the API in your calls to ctypes (and
as was just shown in another thread about 64-bit issues, that's not
always easy).

> This is not to say that it is not a noble goal, but I think it remains to
> be shown that Parrot is actually a solution here.

Parrot definitely has to show itself still. But a year ago Sam Ruby
reported on his efforts of making Python work on Parrot, and he
sounded like it was very a feasible proposition.

> Parrot has been around for quite a while now without accomplishing anything
> much of practical value.  Does anyone _use_ it for Ruby, JavaScript, or Tcl?
> (I know no one uses it for Perl 6 ;)
>
> For five years of development by a pretty large community, that's not showing
> a lot.  The reason I suspected a joke is that you seem to want to discard a
> fairly good existing widely used solution in favor of one that's just vapor
> right now.  Granted Py3k is a ways off, but it's not /that/ far off.  We're
> talking about a year or two here.  Is Parrot going to be as solid in a year
> as ctypes already is?  I doubt it.

That's not exactly the point I am making. I find Parrot's approach,
assuming the project won't fail due to internal friction, much more
long-term viable than ctypes. The big difference being (I hope)
introspective generation of APIs rather than having to repeat the
linkage information in each client language.

> If you /really/ want to look outside of the Python community for solutions
> here, the lisp community has thought about this for a long time.  Instead of
> looking at Parrot, you should look at the ffi provided by almost any lisp
> runtime.

This seems a mostly theoretical viewpoint to me. Can you point me to
an example of a Python-like language that is successful in reusing a
Lisp runtime? (And I don't consider Lisp or Scheme Python-like in this
context. ;-)

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