On Thu, Oct 02, 2003 at 07:19:07PM +0100, Barry Scott wrote:
> What would be really cool is that I could do:
>
> import svn
>
> list = svn.ls( 'http://x/repos/foo' )
>
> list = svn.status( r'c:\workspace\svn' )
We could add a few, key functions/classes into the svn/__init__.py module
to do stuff like this.
> Of course this overlooks the problem of the options on each command.
Keyword arguments, my boy... keyword arguments.
>...
> At 02-10-2003 15:18, C. Michael Pilato wrote:
> >Barry Scott <barry@barrys-emacs.org> writes:
> >
> > > How about this:
> > >
> > > in svn.apr expose the apr_* from core
> > > in svn.config export the svn_config_* from core
> > > etc.
> >
> >I think the goal was to try to avoid modules that had, oh, 3 functions
> >in them. :-) I really don't want my programs to look like:
Exactly. I sat down and figured out which libraries "made sense" from the
standpoint of somebody wanted to write Python apps using the SVN
interface. Also, to divide among what kinds of link dependencies would get
created (e.g. svn.fs had to be separated from svn.client). That resulted
in a set of seven: client, core, delta, fs, ra, repos, wc
> > import svn.apr
> > import svn.pool
> > import svn.config
> > import svn.path
> > import svn.io
> > ...
> >
> >It just gets kinda junky, ya know? On the flip side, I'm so
> >completely picky about consistency and such, so I hear you, I really
> >do.
Well, the prefix-dropping stuff that svn.fs does should be replicated to
the others. As pointed out, that is a bit more troublesome for svn.core.
However, note that svn.core only has a *very few* APR functions in it. In
general, Python supplies a very broad set of tools for portability, so the
only reason we "need" access to APR function is where the SVN APIs require
APR objects. And even then, it could be possible to push all that down
into the bindings with some good typemaps.
The svn.core module is probably exposing "too much" stuff, too. There are
a lot of %ignore lines in core.i, but I bet there should be more. We have
many functions in our low-level libraries which Python just doesn't need.
For example, svn_io_dir_walk or svn_io_open_unique_file. All of the
various languages have better ways to do those things.
And svn.core probably should not expose the "opt" stuff at all. Hmm. Well,
it looks like it needs to expose the svn_opt_revision_t structure. But
that is all it should expose from the "svn_opt.h" header.
Yikes. And I see core.TRUE and core.FALSE. Some serious housecleaning is
called for... :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 3 03:20:00 2003