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 Wed May 14 00:56:24 2003