Re: Proof of concept higher-level python bindings for SoC project

On 06/04/2007 8.21, David James wrote:

> To help our Google summer of code students get started, I've
> implemented some simple higher level Python bindings for
> "svn_repos.h". These bindings are by no means complete, but they give
> you an idea of what nice higher-level Python bindings might look like.

Thanks for your work on this. I have not had time to look at the actual code
you wrote, so I'm basing this answer merely on reading this mail.

> Some folks, who are used to our SWIG bindings, might miss some
> features that are provided by our old bindings:

I think it should be cleared that most of these features could easily be
implemented on the top of the low-level ctypes bindings. So I don't think we
should consider them "lost" just because you're using ctypes: it's basically a
matter of deciding whether we want them or not.

> - Our SWIG bindings convert "svn_error_t" return codes into exceptions

I personally consider this a feature. In Python, it's really Pythonic that
errors are reported in form of exceptions. Having to look at the error code of
each function I call is something I wouldn't expect from a Python library.

Anyway, this can be implemented very easily in ctypes, given that "restype"
can be a callable:

def check_svn_error_t(value):
     value = svn_error_t(value)
     if value == 0: # or whatever is the error code
        raise SvnError(value, ...)
     return value

for f in [all functions wrapped with ctypes]:
     if f.restype == svn_error_t:
        f.restype = check_svn_error_t

So I guess it's just a matter of deciding if we like it or not. I'm +1 on it.

> - Our SWIG bindings convert APR arrays and APR hashes into Python
> arrays and Python hashes, if you write a whole bunch of boilerplate
> typemap code.

I guess that depends on how well you manage to wrap APR data structures in
Python. My own personal preference is to provide a wrapper class built over
the C-level APR functions, and making the class fully duckable with regular
Python lists and maps (as much as possible). This lets the users write natural
Python code to manage APR containers, and also allow maximum performance
because data structures must not be converted every time between Python and APR.

> - Our SWIG bindings convert some pointer types into output
> arguments, if you write the necessary typemap code to do this
> conversion.

Well, given that Python support multiple return types, I guess that's really
necessary. How are you going to, eg., wrap a C function that returns an
integer by the means of a pointer (given that the 'int' instances are
immutable)? Leaking ctypes' specific types like c_int() into Python code
doesn't feel like a good design either. You don't buy much in this case by
forcing the user not to use natural data types, and make them goo "eewww" when
they get weird exceptions because of c_int leaking around.

> After working with ctypes for a while, I don't miss any of the
> features of our SWIG bindings. In fact, I actually am happy that the
> ctypes low-level API is exactly the same as our Subversion C API,
> because it is easier for me to understand -- I don't need to think
> about typemaps when I read the doxygen documentation.

Remember that the Subversion API is not really Pythonic, nor very clear or
well documented for a newbie. If your target are Subversion C programmers
moving to Python, that'd would be a nice task. But you're doing a proof of
concept for a "higher-level" API, so sticking **too much** to the C API
doesn't look like something that should be preserved.

> In my opinion, ctypes is much, much better than SWIG for what we want
> to do.

I mostly agree, based on previous experience with both tools (and similar
tools). Of course, SWIG (and SWIG-like tools) are still useful for
cross-language bindings (if that's a plus), and for C++ APIs (which Subversion
hasn't got).

HTH!

-- 
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org