Walter Mundt wrote:
> Here's what I've got from before I stopped working. I'm not including a
> log-message formatted summary because THIS PATCH IS NOT READY. djames
> asked that I post it so everyone can get an idea of where things stand.
Thanks.
> The AuthBaton stuff in core.py is more of a thought experiment than
> anything, thinking about whether I want to separately wrap Subversion
> auth_baton objects in a Python class. Auth batons include a "parameter"
> map which is an apr_hash_t whole values vary in type depending on what
> key you look up; thus the calls to (nonexistent) helpers which would try
> to sort that out and marshal to Python in some mostly-sane manner. Still
> no decision on whether this makes sense/is important enough to justify
> building/is possible to do sanely given the lack of strong typing
> guarantees on the auth parameters.
Given the lack of general typing guarantees, I think the only thing you
can sensibly do is only support access to auth parameters whose type you
know about, and throw an exception on an attempt to set or get a
parameter that the bindings code has not yet been explicitly taught about.
> The new Client class basically attempts to encapsulate the
> svn_client_ctx_t; rather unambitious, but I'm trying to keep a
> reasonable amount of congruence between the Python bindings and the C
> API where I can.
Good.
> I'm planning on writing a script to parse XML output from doxygen to
> generate templates for the docstrings for the Client functions with
> direct equivalents in the C API. Thus the total lack of any docs on
> those for the moment.
I'm not sure that the C docstrings will be adequately relevant for
Python in many cases.
> Finally, I've left off the numeric suffixes on function variants
> throughout. This is because most of the changes seem to involve
> introducing new parameters. In Python, we can just add extra
> optional/defaulted parameters and document "current" and (if needed)
> "deprecated" call semantics without needing to introduce new function
> names.
I disagree with this quite strongly. There's absolutely NO guarantee
that all C API revbumping will be compatible with the above methods.
> +def _get_poolarg(pool):
> + """Returns an empty tuple if pool is None, or (pool,) otherwise, for use in
> + functions taking an optional pool parameter."""
> + if pool is None:
> + return ()
> + else:
> + return (pool,)
...
> + def mkdir(self, paths, pool = None):
> + poolarg = core._get_poolarg(pool)
> + return mkdir2(paths, self.ctx, *poolarg)
...
This poolarg stuff seems a little messy - perhaps we should instead
adjust the underlying wrapper code to understand None directly, rather
than insisting on the presence/absence of the pool parameter.
Max.
Received on Mon Jul 10 18:46:26 2006