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

On Saturday 01 November 2003 10:47 am, Barry Scott wrote:
> pysvn is a Python interface to the Subversion client functionality.
> It is available in source and win32 binary kits from
> http://www.barrys-emacs.org/pysvn/.
>
> The main purpose of this release is to get feedback on the API design.

[I haven't yet looked at the actual code, only at the docs.]

Do we need the "svn_" prefixes everywhere? All these things
are already in the "pysvn" module, after all.

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

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)

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 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.

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.

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.

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

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

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