Re: Subversion Python bindings

Barry Scott wrote:

> I'll add users@subversion.tigris.org so other see the discussion. There
> are a number of comments there already.
>
> Barry
>
> At 03-11-2003 20:18, John Barstow wrote:
>
>> Attached is a first pass at doc strings for just over half the
>> methods. I
>> hope to work on the other half tonight; I also have a HOWTO with common
>> workflow tasks in the works.
>>
>> In reviewing, I noticed that the ability to relocate the repository
>> seems to
>> be missing (svn switch --relocate); this is important when the
>> repository
>> URL changes.
>
>
> O.K. I'll look into it.
>
> Also how is the revision range passed to svn_update? That one for the
> rapidsvn folks.
>
>> > What are think a "familiar status code" looks like in python?
>> > repr would tell you what it was "<svn_revision_kind_t head>" for
>> example.
>> I was thinking of the A, M, ? codes the command line returns. An
>> enumeration works better if we add repr.
>
>
> What is "A, M,"?
>
> 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.

There are certainly other python modules where keyword avoidance has to
be overcome. Which is a bigger wort, having everything (well, almost
everything) prefixed with 'svn_' or having the import command be
'import_', 'imp', ...

I can understand the virtue of having consistency between naming on the
python side and c++ side (I like to write c++ extension modules myself)
but is this really such a big maintenance trap? Anyone who writes python
already knows that 'import' is a keyword and this the corresponding
python method must be called something like that. Ditto with switch on
the c++ side. I don't see this as the kind of thing that ends up causing
some hapless programmer to sit there scratching their heads over an
exception for 2 days or from introducing some lurking bug beast that
would lay dormant until one day.

You could look at it this way: you've already gone down the road to
deliver a 'pythonic' interface as opposed to the already existing c-ish
one. Having done that why have the c implementation continue to bleed
through like this? Contrary to what you said earlier I don't think the
'average' consumer of this module (at least down the road) will ever
look at the C source to understand the interface. That user is going to
be interesting purely in getting the good pythonic interface to svn.
That person will immediately jump up and post to a mailing list about
how dumb it is to have all the methods prefixed with 'svn_' creating all
sorts of useless traffic. ;-)

-- 
Jens B. Jorgensen
jens.jorgensen@tallan.com
"With a focused commitment to our clients and our people, we deliver value through customized technology solutions."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org