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

Re: Python Command-line Client Bindings

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-06-29 19:50:51 CEST

Garrett Rooney <rooneg@electricjellyfish.net> writes:

> David James wrote:
> > Here's an example of a function (from main.c) which is difficult to
> > Swigify without using malloc/free.
> > int svn_cmdline_main (int argc, const char * const *argv)
> > (This is the 'main' function from clients/cmdline/main.c)
> > When you call the svn_cmdline_main function using Python strings, we
> > need to allocate memory to store C-compatible versions of these
> > strings. We can easily accomplish this using malloc/free. Allocating
> > a
> > brand new APR pool for this purpose would be very wasteful,
> > especially since the purpose of the svn_cmdline_main function
> > already allocates its own root pool. So, I think the best solution
> > here is to use malloc/free. What do you think?
> What's the point of calling the command line client's main from python
> in the first place? Won't that just call through to the underlying
> svn_client_foo functions, bypassing all the python wrappers you intend
> to test by building this 'command line client in python'?

I have to say (and have said in a few private email already today)
that I'm quite confused by the point of this whole effort.

If the goal is to make the Python bindings testable, I think it's
overkill. The bindings are very thin; smaller test scripts would work
just fine. I mean, all you really need to test is that data can get
from Python to C and back again -- 98% of the work a Python bindings
cmdline client would do is down in the C libraries, which are already
well-covered by our test framework.

If the goal if to find holes in our Python bindings coverage, I don't
think those of us that actually work on those bindings need the help.
With just a moderate knowledge of SWIG, one can visually scan our C
API and know which interfaces are and aren't going to be troublesome
for SWIG to deal with.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 29 19:53:39 2005

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.