Greg Stein wrote:
>>Okay, but then then please don't call it "util". util sounds much like
>>optional, but it contains authentication stuff and pools, so it's
>>actually quite important to any application. I suggest moving core
>>things from util into a "core" extension module, if we can't have one
>>module per one header (which I still prefer, actually).
>
> Ah. 'core' would be fine -- no problems there. We can also have a small
> util.py for backwards compat. ('from core import *')
So it is core then. But do we need to keep backward compatability at
this time? I'm imagining somebody trying out the python bindings for 1.0
and wondering why stuff from core appears in util.
>>Yes, agreed. I was actually only picking up cmpilato's file name
>>suggestions. My idea of the bindings is this:
>>
>>libsvn/ # contains the extension modules and those only
>>libsvn/_client.so
>>libsvn/_wc.so
>>libsvn/client.py
>>libsvn/wc.py
>>...
>>
>>subversion/ # contains additional python classes and functions
>>subversion/client.py
>>subversion/wc.py
>>...
>
> Rename that to 'svn/' and I like this arrangement.
I have no quarrel with that, I just thought that libsvn and subversion
aren't easily mixed-up by the programmer, whereas libsvn and svn sounds
a little too similar.
> I might also say that the libsvn/ modules do not remove the function
> prefixes
One one hand, this would make sense because we expect libsvn just to be
a wrapper around the C libraries. On the other hand, we're coming from
Python and libsvn.client.svn_client_checkout is very verbose.
> while the svn/ modules import all the functions *with* their prefixes
> removed.
Hmm, that would lead to an ugly import-rename hack again. SWIG can do
nice renaming using the %rename directive. This way, we would have a
consistent naming scheme for all languages. The question is whether all
other languages support module namespaces like python.
I really have no clear opinion on this. I could live with your
suggestion leaving the names in libsvn as they are in the headers and do
the import-rename hack in svn. I'm just wondering whether there might be
a better and cleaner way.
> IOW, libsvn is simple wrappers to expose the functionality, and the
> svn modules are the higher-level bits and ease-of-use items.
That's the way I thought about it.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 13 01:00:46 2003