cmpilato@collab.net wrote:
> So, there are some "action items" contained in this little exchange.
>
> Let's clear up the other ones:
>
> - naming schemes -- do we agree that the old fs.py renaming stuff
> sucks, so go back to using the full function names?
For now, yes. I will write down my ideas and questions about a general
(re)naming scheme and send them to the list tomorrow or so. I have them
in my head, but it takes some time writing them down.
> - headers-to-modules ratio -- we'd like to see each header
> handled by its own module, right?
Preferrably. This way we can tell people: simply look at the C headers
for documentation. They will not have to be able to understand C code
but at least they will be able to find what they're looking for.
> Are there other changes of interest that I'm forgetting?
I've been thinking about client.py, fs.py, wc.py, etc. vs. FileDiff.py,
WorkingCopy.py, etc. I think these should be in different packages, so
people will not mix-up WorkingCopy.py with wc.py or Client.py with
client.py.
Also, many projects like Zope3 and Twisted use lower case for module
names and I really like this naming scheme. This way, you won't mix up
module names with class names (e.g. FileDiff could be the module or the
class FileDiff.FileDiff). However, then we'd definitely need different
packages.
Here's my suggestion: The package 'subversion' contains pure-python code
(e.g. filediff). The package 'libsvn' contains the output generated by
SWIG. This way, when you import stuff from libsvn, you know where things
come from and where to look for documentation. Problem: breaks all
python code (which is however, very easy to fix).
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 12 22:57:35 2003