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

Re: pysvn 0.1.1 Python interface to Subversion released for review and testing

From: Barry Scott <barry_at_barrys-emacs.org>
Date: 2003-11-01 21:04:53 CET

At 01-11-2003 15:57, Gareth McCaughan wrote:
>Do we need the "svn_" prefixes everywhere? All these things
>are already in the "pysvn" module, after all.

I find that I keep on having to refer to the C code to figure out things
and the one-to-one naming of enums may make things easier.

>Class names in Python generally have initial capital letters: pysvn.Client,


>It would be nice to have less cumbersome ways of constructing
>a pysvn.revision object.
> # might actually be better to make this map names to already-made
> # revision objects.
> _kind_map = { "head": opt_revision_kind.head, <etc> }
> def rev(special=None, date=None, number=None):
> if (special is None) _ (date is None) + (number is None) != 2:
> # complain: exactly one should be passed in
> if special:
> return Revision(_kind_map[special])
> if date: return Revision(opt_revision_kind.date, date)
> if number: return Revision(opt_revision_kind.number, number)

If I lose the enums and use strings for kind I'd have the same interface.

>It would be nice (I'm not sure whether it would be *good*) to allow
>a string to be used as a revision date, to be parsed using time.strptime.

I don't think string formats is the business of pysvn.
Just call time.strptime on your string and pass in the float time.

>I don't like seeing member variables exposed as part of the documented
>interface of a class. Especially not for setting. Especially-squared not
>when there's no cause for them ever to change after construction.
>So I'd advise losing the last two examples of the use of the pysvn.revision

The class is implemented completely in C++ no internals are exposed.
I could make them read-only properties after construction.

>For reasons of efficiency, svn_client_revert may be about to change
>so that it takes a list of paths. If not, then it's likely that a new
>function that takes a list of paths and reverts them all will be
>added. In either case, you'll want to support that.

That will be easy to support.

>What happens when one of these svn_xxx functions returns? Do you
>return a wrapped svn_error_t, or do you never return anything and
>raise an exception when something goes wrong? I'd vote for the latter.

You see a RuntimeError exception with the text of the svn_error_t in it.
I need to add a ClientError exception rather then use RuntimeError.

>Some of these functions have a "recurse" argument that defaults to
>False, where the corresponding svn subcommand defaults to recursing.
>That might be confusing.

I used the default from the svncpp C++ code as far as I remember. They
think its better to default recurse off. In a GUI the recurse is not
required, in a CLI replacement it is required.

>There are a lot of arguments called "path". Can they take URLs pointing
>into repositories as well, where appropriate?

If svn supports a url in the path args then yes. I've used the
naming from svncpp.

>Gareth McCaughan
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 1 21:05:42 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.