Sorry about the delay; very busy week at work. I'll be getting you
updates over the weekend.
On Wed, 2003-11-05 at 05:14, Barry Scott wrote:
> What is "A, M,"?
>
The status codes shown when you do "svn st" at the command line ('A' for
added, 'D' for removed, etc...)
> O.K. I'll try the enum in a python type and we can see how that works out.
>
> > > What are you thinking of? I think being pythonic is very important.
> >Couple of things:
> >The svn_ prefix is redundant. I believe client.add() is more pythonic than
> >client.svn_add().
>
> I want all commands to have the same naming pattern. If I do not have a
> prefix then I end up with one command that is a keyword, "import". There
> is a problem in C++ with the "switch" command. The C++ code uses cmd_ as
> the prefix.
>
I was thinking about this. What if we left the C++ as it is, and simply
wrapped another class around it with more pythonic names?
For example:
(pysvn.py)
import libpysvn #C++ extension
class client:
def __init__(self):
self.libsvn = libpysvn.client()
def add(path):
self.libsvn.svn_add(path)
The user gets pythonic names, you keep the C++ code clean and obvious.
> >The enumerations could be better named(svn_revision_kind_t is hardly
> >intuitive).
> >We should be more consistent about path vs. path_list. Ideally both would
> >work; I should be able to write both of the following:
> >
> >client.add("foo.c")
> >newfiles = ["bar.c", "baz/"]
> >client.add(newfiles)
>
> O.K. The code is easy, I wonder if there is a down side?
>
> >Having recurse default to False in places where the command line usually
> >defaults to True will probably cause problems. It's documented but not
> >obvious. It's surprising to do a checkout and only get the top-level
> >directory.
>
> O.K. I'll default all to recurse True. Your the second person to say the
> defaults are wrong.
>
I seem to recall that there were a couple of commands that were
non-recursive by default at the command line. If that's still the case,
we'll also want those particular commands to default the same way.
> >Lastly, I would expect to pass either a revision number or a revision kind
> >to the client api. So:
> >
> >client.update("foo.c", 1579)
> >client.update("foo.c", revision.HEAD)
>
> The goal of the API is to be obvious to use, extensible and error free to use.
> I'm not convinced that adding this sort of short hand is good.
Well, you're always passing either a number or one of the keywords as a
revision. I think this is the obvious way to do it, but it's definitely
not a big deal to do it the current way.
> I like the way the keywords make it clear which booleans you are setting.
>
> >As an example, here's the snippet I would like to write:
> >import pysvn
> >client = pysvn.client()
> >wc = "/project/subversion"
> >client.update(wc)
> ># make some changes
> >client.add("foo.c")
> >client.remove("bar.c")
> >#add all unversioned files
> >changedfiles = client.status(wc)
> >client.add([s.file for s in changedfiles if s.status ==
> >pysvn.status.UNVERSIONED])
> >client.revert("tmp/", True)
> >client.commit(wc)
>
> This requires:
> * change the client function names. See above for import problem
We will have come up with another name for import.
> * remove keyword recurse from revert. That would be inconsistent.
I meant the True to be the recurse argument.
> * support path and lists_of_paths everywhere. Should be reasonable to do.
> * find short name for svn enums. removing the svn_ prefix is easy
> but I'm not sure I should remove much more. Over time we may need to
> expose other enums that will conflict with contraction to just status.
> the _t suffix can go as well.
A wrapper class could allow us to leave the C++ as is.
> * upper case all enum values. Why did you want the names upper cased?
That's my coding style; holdover from my C++ days, I guess, when all
constants were uppercased. We should do whatever the Python style guide
says.
John C Barstow
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 7 08:55:09 2003