package blues

Oivvio Polite oivvio at cajal.mbb.ki.se
Wed Aug 2 10:58:10 EDT 2000


Greetings.

We're building this package and we're deciding which classes should go in
which modules and which modules should go into which subpackages.

The first intuitive approach was to try to map the class structure onto a
directory/files structure (in the style of Java).

This turned out to be a bad idea, simply because python is not meant to be
like java.
The identifiers in the imports become very long and (as module name often
equals class name) utterly confusing.

So I took  a look at NumPy and a couple of other packages that I've
installed and found out that the directory structure of these packages is
very shallow.

They typically cram a lot of classes and functions into every module. Having
a lot of stuff in one file never feels nice. And in a collaborative project
like ours it creates an other problem. If I check out one file from the our
version control db, it gets locked. The larger the files the greater chances
that an other programmer will need to work on the same files as me.

So we looked for something resembling the include of C. A thread out here
mentioned execfile(). But that doesn't seem like a very nice solution.

This post turned out a bit confused, but so are the issues at hand.
I think that some of you will recognize our frustration and I hope that
you've found ways to deal with it.

oivvio





More information about the Python-list mailing list