You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Barry Scott <ba...@barrys-emacs.org> on 2003/09/30 22:48:49 UTC

SVN Python questions and suggestions

Why do you have libsvn and svn packages?

I would have thought you only need one package svn. The DLLs can be in
the same dir as the public interface .py files. (Is this legacy?)

Why are the names of the python extension DLLs so short? Isn't this
asking for trouble with DLL name collisions with other apps?
The word count extension would be _wc would it not?

I Suggest that the DDLs all have an _svn prefix. For example _svn_wc.dll

Why not rename to .pyd as is the convention on windows python.

Barry



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

Re: SVN Python questions and suggestions

Posted by Barry Scott <ba...@barrys-emacs.org>.
At 03-10-2003 02:15, Greg Stein wrote:
>On Thu, Oct 02, 2003 at 07:19:07PM +0100, Barry Scott wrote:
> > What would be really cool is that I could do:
> >
> > import svn
> >
> > list = svn.ls( 'http://x/repos/foo' )
> >
> > list = svn.status( r'c:\workspace\svn' )
>
>We could add a few, key functions/classes into the svn/__init__.py module
>to do stuff like this.
>
> > Of course this overlooks the problem of the options on each command.
>
>Keyword arguments, my boy... keyword arguments.

The other way might be to make svn.ls a class and be able to set options 
with set methods. I'm hungry to prototype this once the binding work 
enough. Does python
version of svn.exe interest you? That's what I aiming to build so that I get
all the building blocks for doing everything with svn from python that is 
useful.
Then I can go and build high level tools up top of svn.

Barry




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

Re: SVN Python questions and suggestions

Posted by Greg Stein <gs...@lyra.org>.
On Thu, Oct 02, 2003 at 07:19:07PM +0100, Barry Scott wrote:
> What would be really cool is that I could do:
> 
> import svn
> 
> list = svn.ls( 'http://x/repos/foo' )
> 
> list = svn.status( r'c:\workspace\svn' )

We could add a few, key functions/classes into the svn/__init__.py module
to do stuff like this.

> Of course this overlooks the problem of the options on each command.

Keyword arguments, my boy... keyword arguments.

>...
> At 02-10-2003 15:18, C. Michael Pilato wrote:
> >Barry Scott <ba...@barrys-emacs.org> writes:
> >
> > > How about this:
> > >
> > > in svn.apr expose the apr_* from core
> > > in svn.config export the svn_config_* from core
> > > etc.
> >
> >I think the goal was to try to avoid modules that had, oh, 3 functions
> >in them. :-)  I really don't want my programs to look like:

Exactly. I sat down and figured out which libraries "made sense" from the
standpoint of somebody wanted to write Python apps using the SVN
interface. Also, to divide among what kinds of link dependencies would get
created (e.g. svn.fs had to be separated from svn.client). That resulted
in a set of seven: client, core, delta, fs, ra, repos, wc

> >    import svn.apr
> >    import svn.pool
> >    import svn.config
> >    import svn.path
> >    import svn.io
> >    ...
> >
> >It just gets kinda junky, ya know?  On the flip side, I'm so
> >completely picky about consistency and such, so I hear you, I really
> >do.

Well, the prefix-dropping stuff that svn.fs does should be replicated to
the others. As pointed out, that is a bit more troublesome for svn.core.

However, note that svn.core only has a *very few* APR functions in it. In
general, Python supplies a very broad set of tools for portability, so the
only reason we "need" access to APR function is where the SVN APIs require
APR objects. And even then, it could be possible to push all that down
into the bindings with some good typemaps.

The svn.core module is probably exposing "too much" stuff, too. There are
a lot of %ignore lines in core.i, but I bet there should be more. We have
many functions in our low-level libraries which Python just doesn't need.
For example, svn_io_dir_walk or svn_io_open_unique_file. All of the
various languages have better ways to do those things.

And svn.core probably should not expose the "opt" stuff at all. Hmm. Well,
it looks like it needs to expose the svn_opt_revision_t structure. But
that is all it should expose from the "svn_opt.h" header.

Yikes. And I see core.TRUE and core.FALSE. Some serious housecleaning is
called for... :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

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

Re: SVN Python questions and suggestions

Posted by Barry Scott <ba...@barrys-emacs.org>.
What would be really cool is that I could do:

import svn

list = svn.ls( 'http://x/repos/foo' )

list = svn.status( r'c:\workspace\svn' )

Of course this overlooks the problem of the options on each command.

Now that solves the problem of where to put all them functions as
you no longer care!

         Barry


At 02-10-2003 15:18, C. Michael Pilato wrote:
>Barry Scott <ba...@barrys-emacs.org> writes:
>
> > How about this:
> >
> > in svn.apr expose the apr_* from core
> > in svn.config export the svn_config_* from core
> > etc.
>
>I think the goal was to try to avoid modules that had, oh, 3 functions
>in them. :-)  I really don't want my programs to look like:
>
>    import svn.apr
>    import svn.pool
>    import svn.config
>    import svn.path
>    import svn.io
>    ...
>
>It just gets kinda junky, ya know?  On the flip side, I'm so
>completely picky about consistency and such, so I hear you, I really
>do.
>
>Whatever the community decides is fine with me.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org



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

Re: SVN Python questions and suggestions

Posted by "C. Michael Pilato" <cm...@collab.net>.
Barry Scott <ba...@barrys-emacs.org> writes:

> How about this:
> 
> in svn.apr expose the apr_* from core
> in svn.config export the svn_config_* from core
> etc.

I think the goal was to try to avoid modules that had, oh, 3 functions
in them. :-)  I really don't want my programs to look like:

   import svn.apr
   import svn.pool
   import svn.config
   import svn.path
   import svn.io
   ...

It just gets kinda junky, ya know?  On the flip side, I'm so
completely picky about consistency and such, so I hear you, I really
do.  

Whatever the community decides is fine with me.

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

Re: SVN Python questions and suggestions

Posted by Barry Scott <ba...@barrys-emacs.org>.
How about this:

in svn.apr expose the apr_* from core
in svn.config export the svn_config_* from core
etc.

Oh and get ride of the svn.util as it is a subset of svn.core.

Barry

At 01-10-2003 22:24, C. Michael Pilato wrote:
>Barry Scott <ba...@barrys-emacs.org> writes:
>
> > For the svn.core you can strip the svn_ prefix of course.
>
>Well, I thought about that, but it turns out not to be true.  svn.core
>also exposes some APR functions (svn.core.apr_initialize(), for
>example) -- so to be strictly safe, we can't strip anything there.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org



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

Re: SVN Python questions and suggestions

Posted by "C. Michael Pilato" <cm...@collab.net>.
Barry Scott <ba...@barrys-emacs.org> writes:

> For the svn.core you can strip the svn_ prefix of course.

Well, I thought about that, but it turns out not to be true.  svn.core
also exposes some APR functions (svn.core.apr_initialize(), for
example) -- so to be strictly safe, we can't strip anything there.

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

Re: SVN Python questions and suggestions

Posted by Barry Scott <ba...@barrys-emacs.org>.
That'd be wonderful, in my opinion.  We do this with the 'svn.fs'
>package -- I have no idea why we don't also do it with the others.  I
>think all the but the 'svn.core' package should have the
>'svn_PACKAGE_' stripped (can't do 'svn.core' because it covers many
>namespaces).

I was concerned about DLL name space in my initial mail, not the python
one, but...

Yes wonderful. I avoid from blah import * for maintainability reasons.

For the svn.core you can strip the svn_ prefix of course.

Barry



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

Re: SVN Python questions and suggestions

Posted by Michael Wood <mw...@its.uct.ac.za>.
On Wed, Oct 01, 2003 at 08:51:46AM -0500, C. Michael Pilato wrote:
> SLOGEN <je...@slog.dk> writes:
> 
[snip]
> > which brings up the question of why it's:
> > 
> >    svn.wc.svn_wc_entry()
> > 
> > and not simply:
> > 
> >    svn.wc.entry()
> > 
> > pyGTK changed notation like that not too long ago
> 
> That'd be wonderful, in my opinion.  We do this with the 'svn.fs'
> package -- I have no idea why we don't also do it with the others.  I
> think all the but the 'svn.core' package should have the
> 'svn_PACKAGE_' stripped (can't do 'svn.core' because it covers many
> namespaces).
[snip]

I imagine the only reason is:  Nobody has submitted a patch to do this.

-- 
Michael Wood <mw...@its.uct.ac.za>

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

Re: SVN Python questions and suggestions

Posted by "C. Michael Pilato" <cm...@collab.net>.
SLOGEN <je...@slog.dk> writes:

> C. Michael Pilato wrote:
> 
> > Besides that, while our example code might use 'from svn import wc',
> > if you are concerned about namespace clashes, you can always just
> > 'import svn.wc' and references things like 'svn.wc.svn_wc_entry()'.
> 
> which brings up the question of why it's:
> 
>    svn.wc.svn_wc_entry()
> 
> and not simply:
> 
>    svn.wc.entry()
> 
> pyGTK changed notation like that not too long ago

That'd be wonderful, in my opinion.  We do this with the 'svn.fs'
package -- I have no idea why we don't also do it with the others.  I
think all the but the 'svn.core' package should have the
'svn_PACKAGE_' stripped (can't do 'svn.core' because it covers many
namespaces).

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

Re: SVN Python questions and suggestions

Posted by SLOGEN <je...@slog.dk>.
C. Michael Pilato wrote:

> Besides that, while our example code might use 'from svn import wc',
> if you are concerned about namespace clashes, you can always just
> 'import svn.wc' and references things like 'svn.wc.svn_wc_entry()'.

which brings up the question of why it's:

   svn.wc.svn_wc_entry()

and not simply:

   svn.wc.entry()

pyGTK changed notation like that not too long ago

-- 
Helge


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

Re: SVN Python questions and suggestions

Posted by "C. Michael Pilato" <cm...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:

> > Why are the names of the python extension DLLs so short? Isn't this
> > asking for trouble with DLL name collisions with other apps?
> > The word count extension would be _wc would it not?
> 
> Python loads libraries from specific files; there's no ambiguity.

Besides that, while our example code might use 'from svn import wc',
if you are concerned about namespace clashes, you can always just
'import svn.wc' and references things like 'svn.wc.svn_wc_entry()'.

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

Re: SVN Python questions and suggestions

Posted by Barry Scott <ba...@barrys-emacs.org>.
At 01-10-2003 00:33, Branko Čibej wrote:
>Barry Scott wrote:
>
> > Why do you have libsvn and svn packages?
> >
> > I would have thought you only need one package svn. The DLLs can be in
> > the same dir as the public interface .py files. (Is this legacy?)
>
>Because there are two levels of interfaces: libsvn just exposes the C
>api in Python; svn builds on top of that.

I was looking at client and its got no value add in svn from libsvn.
But I did find the additions for other like delta.

> > Why are the names of the python extension DLLs so short? Isn't this
> > asking for trouble with DLL name collisions with other apps?
> > The word count extension would be _wc would it not?
>
>Python loads libraries from specific files; there's no ambiguity.

Agreed.

> > Why not rename to .pyd as is the convention on windows python.
>
>Because .pyd is used by standalone native extensions that are imported
>directly into Python scripts. These DLLs aren't meant to be used that
>way, that's why we have the Python wrappers.

O.K. However I got errors loading the DLLs because the DDLs like
LIBEAY32.DLL are not on my PATH. Simple to fix either by forcing
c:\program files\subversion on to the PATH. Or but putting the DLLs
into libsvn.

This is a question for the INNO world, didn't the svn path get added on
install?

>--
>Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org



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

Re: SVN Python questions and suggestions

Posted by Branko Čibej <br...@xbc.nu>.
Barry Scott wrote:

> Why do you have libsvn and svn packages?
>
> I would have thought you only need one package svn. The DLLs can be in
> the same dir as the public interface .py files. (Is this legacy?)

Because there are two levels of interfaces: libsvn just exposes the C
api in Python; svn builds on top of that.

> Why are the names of the python extension DLLs so short? Isn't this
> asking for trouble with DLL name collisions with other apps?
> The word count extension would be _wc would it not?

Python loads libraries from specific files; there's no ambiguity.

> I Suggest that the DDLs all have an _svn prefix. For example _svn_wc.dll

Like I said, there's no need.

> Why not rename to .pyd as is the convention on windows python.

Because .pyd is used by standalone native extensions that are imported
directly into Python scripts. These DLLs aren't meant to be used that
way, that's why we have the Python wrappers.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/


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