[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ctypes + Subversion + a few high level python modules = really great python bindings

From: Sage La Torra <sagelt_at_gmail.com>
Date: 2007-04-10 08:17:24 CEST

On 4/10/07, David James <james@cs.toronto.edu> wrote:
> > If ctypes is as great as it sounds, a fun project would be to port it
> > to Ruby and Perl :)
>
> Perl has Inline::C and Ruby has DL. I don't know if they are as good
> as ctypes. I saw this post on the users@ list:
> http://svn.haxx.se/users/archive-2005-06/0573.shtml
>

You're right about Inline::C, among other cool Perl stuff. Perl has
some very good support for C in a variety of forms already, and as far
as I know this is being preserved in Perl 6. If you can make a C
binding, it can pretty much work in Perl, so don't worry too much
about that.

> I don't think that Perl or Ruby need to switch away from SWIG in order
> to benefit from our higher-level object model. I only wish to upgrade
> our Python bindings to use ctypes because ctypes is incredibly good
> and makes everything easy in the Python bindings. :)

I'd agree with this, especially since the Perl and Ruby bindings
(which seem to be the main concerns) are not as badly in need of an
update. In addition, once we start talking high-level we pretty much
have to give up language interoperability. It would be nice to have a
high-level interface that's the same in Python, Perl and Ruby, but
this just isn't realistic.

I can understand the problem of having bindings for different
languages coming about in different ways, but I think this is the best
way to do it with current interoperability tools.

-Sage

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 10 08:17:38 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.