[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: Blair Zajac <blair_at_orcaware.com>
Date: 2007-04-10 04:15:35 CEST

On Apr 9, 2007, at 6:46 PM, David James wrote:

>
> If you're familiar with our Python SWIG bindings, you'll know that our
> low-level bindings are, unfortunately, full of bugs. If you try to
> write a simple Python program which uses the RA layer, you'll find,
> unfortunately, that your program may crash with little explanation as
> to why. As a developer who loves working with Python, I find these
> unexplained crashes very frustrating.
>
> These crashes in our SWIG bindings are usually caused by bugs in our
> SWIG typemaps, so they shouldn't be blamed on SWIG itself.
> Fortunately, if we switch from SWIG to ctypes, we won't have to spend
> any more time writing or debugging typemaps anymore!

Are these bugs in the typemaps specific to the Python SWIG typemaps
or for all SWIG bindings? I'd rather not see effort split between a
ctypes build and a SWIG bindings that Perl and Ruby depend upon.
>
>
> Here's an example code snippet, which atomically replaces the "abc"
> branch at "http://svn.collab.net/repos/svn/branches/abc" with a brand
> new copy of trunk. This code snippet is useful for folks who want to
> rebranch in a single atomic commit.
>
> client = Client("http://svn.collab.net/repos/svn")
> txn = client.session().txn()
> client.rm("branches/abc")
> client.cp("trunk", "branches/abc")
> txn.commit("Rebranch the abc branch from the latest revision of
> trunk")

Are you basing the high level API on the Ruby API? I recall somebody
stating that the Ruby high level API is very nicely designed. If
we're going to do a rewrite of the Python API, why don't we model it
after the Ruby one?

>
> The above task is significantly easier to implement using csvn
> high-level API than it is using the low-level C API. To implement the
> above functionality using the low-level C API, you would need to drive
> the commit editor by hand, much like mucc does, and this is not
> simple.
>
> (Note: The above code sample doesn't work yet, because I haven't
> implemented the "cp" function yet in the high-level bindings. Still,
> "rm", "put", and "mkdir" are already implemented and work great. See
> http://csvn.googlecode.com/svn/trunk/example2.py for a working code
> sample.)
>
> Here's a summary of my proposal:
> 1. Replace the low-level SWIG bindings with low-level ctypes
> bindings. Keep the low-level bindings as simple and as similar to the
> C API as possible so that they don't need much maintenance or
> documentation.
> 2. Write some really nice and easy to use high-level bindings in
> Python, so that end users don't need to use the low-level C API. Write
> detailed, friendly documentation for this new API.
>
> Some questions for the list:
> - Should we choose ctypes over SWIG?
> - Once high-level bindings for csvn are ready, should we deprecate
> the buggy SWIG bindings, and recommend that users pick csvn instead?

I'm really -0 to -1 on this unless we determine how this impacts the
other bindings. I feel we'll be splitting our energy on different
bindings now. If there's work that can be done to the SWIG bindings
that will help Perl and Ruby that would also help Python, I'd rather
see energy go in that direction.

What Python versions does ctypes support? I understand it comes with
Python 2.5, but what's the oldest it supports.

If ctypes is as great as it sounds, a fun project would be to port it
to Ruby and Perl :)

Regards,
Blair

-- 
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 10 04:16:31 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.