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,
>pysvn.Revision.
O.K.
>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
>class.
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