[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-15 12:18:51 CEST

So, what about the patch? Will you or somebody else apply it? 'Cause I
have some more code waiting to be contributed...


Philipp von Weitershausen wrote:
> 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
>>> svn_client_ctx_t_auth_baton_get(ctx).).
>> 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.
> Phil

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 15 12:18:46 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.