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

Re: [PATCH] SWIG bindings refactoring (esp. python)

From: Philipp von Weitershausen <philipp_at_weitershausen.de>
Date: 2003-05-14 00:56:46 CEST

Greg Stein wrote:
> +1 on the patch concept and from a simple review. I haven't applied and
> tested, however.
> -0 on the changes to the SWIG invocation for Java. I'm not sure they are
> ready or want the proxies (yet).

Ok. I guess I was a little too ambitious here. Do you want me to send an
updated version of the patch?

> In a future change, I'd like to see a swig/python/libsvn/ subdir cuz I'm not
> too cozy with the __init__.py addition (but it is fine for now). That would
> alter the copying strategy (and I don't think we want to build in the libsvn
> subdir, altho I'd be find with building into python/build/).

Yeah, that whole build and copy thing is still a myth to me in many
ways. I just browsed through the pieces that I needed to change to make
my patch work.

Actually, I don't really care where we're building stuff. I really like
to view things from the python programmer's perspective which
essentially is something like apt-get install python2.2-subversion and
from svn import <module> ;)

>>When this patch is applied, all python code should still run unless it
>>uses accessor functions. Instead of using accessor functions, you can
>>now simply acquire the attribute of your struct wrapping object to
>>acquire a struct member (e.g. ctx.auth_baton instead of
> All the accessor functions are still present in the wrapper, so shouldn't
> old code continue to work just fine?

Err, no. The accessor functions are in the libsvn._*.so extension
modules, but are not imported to the regular python modules in libsvn.
Thus, they aren't imported into svn either.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 14 00:56:24 2003

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.