Greg Stein wrote:
>> - headers-to-modules ratio -- we'd like to see each header
>> handled by its own module, right?
> Nope. There is a definite cost to having a billion little extension modules.
> That is why a number of them are pulled into the util.i module.
What cost? Performance? Memory?
> If I had my druthers, there would be just a single extension module. As it
> is, I divided them along some probable use-case lines. (and also along the
> dividing line of "will the FS library be around, or will the module only be
> used client-side?")
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).
>>>>The other is to keep our bindings pure, with _fs.so and fs.py, and
>>>>then any wrapper code we do lives in modules with names like
>>>>FileDiff.py, WorkingCopy.py, etc.
> Let's avoid too many Python modules, please. One of the things that I really
> detest about Java is the one-class-one-file approach.
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
subversion/ # contains additional python classes and functions
Developers can then go straight ahead and import from libsvn and
optionally use stuff from the subversion package. Documentation for the
libsvn package can be obtained right from the C headers (or whatever
They also know what to expect in libsvn. I found out about FileDiff and
all these other things only after I browsed the source code. There was
not only no documentation for these things, I also did not expect any
extra python code in the bindings. It seemed quite like a hack.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue May 13 00:20:05 2003