On Sun, 2006-03-12 at 19:31 -0500, Paul Koning wrote:
> >>>>> "Daniel" == Daniel Berlin <firstname.lastname@example.org> writes:
> Daniel> On Fri, 2006-03-10 at 17:34 -0500, Paul Koning wrote:
> >> Unfortunately, I want to do it in Python. And I can't find any
> >> information at all about that. It looks like I have to create a
> >> client_ctx object and put a log_msg_func2 into that, which means I
> >> have to create that function. But what is the function signature
> >> in Python? That's where I lost it before, and I still see no
> >> answer.
> Daniel> The python API is simply a wrapping of the C one.
> Not true. The client_copy function doesn't have the first argument,
> for example. On really careful reading that makes sense, since it
> seems to be an output argument.
Errr, yes, that doesn't make it not a wrapping of the C one however.
It just means that output arguments are transformed in some mechanical
They are returned as return values, and swig takes care of passing in a
temporary one for you.
> Daniel> Thus, the docs are the same, as are the signatures.
> Daniel> However you'd do it in C is usually exactly how you'd do it
> Daniel> in python.
> When the two languages match, yes, it seems that way. But, for
> example, the log_msg_func returns a string via a char ** argument, and
> Python doesn't have any such thing. So it has to be something
> different in Python.
> Expecting people to read cryptic .h files AND even more cryptic SWIG
> files is really not very nice at all.
See, this is where i disagree.
Expecting people to read well documented .h files to discover what the
interface for something is, IMHO, is perfectly fine.
Expecting people to understand that in order to wrap this API into
certain languages, some mechcanical transformations were performed to
it, is also okay.
You are acting like this is a huge secret deal where every single
function has had something different done to it, and it's just not so.
I've written very complex applications using the SWIG API, that use
parts of SVN i was never familiar with at all (IE the fact that i am an
svn developer didn't help me), and it just wasn't that big a problem.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Mar 13 01:48:43 2006