Structuring larger applications - ideas

[Iwan Vosloo]

I know my foreign (to python) one class per module idea is what makes
life more difficult for me here.  And there is an argument to be made
out that it is a stupid remnant I stick to from having used it in other
programming languages (do I have to admit C++ in my background?)  Two
small examples of where it it useful for me:  my development
environment is run by make to a large extent.  Many standard UNIX tools
have the intelligence to deal with filenames, and if you know a file
corresponds to a class, you have a lot more info available in your
makefile.  Also, if I use my version control software (currently gnu
arch) to see what's changed, for example, I get a list of changes files
which again gives me more info because I know a file corresponds to a
class.
So, I can do a number of such small things using that convention that
works well with standard old UNIX tools.  And I find that valuable.

As for the dependencies- I'm trying to keep the specification of them
simple.  From a design point of view, it makes sense to me to only
specify ONCE that largeish-collection-of-classes-A depends on
largeish-collection-of-classes-B.  As another simple small example: say
I change the name of large-collection-of-classes-B - this way I only
need to do it once, else I need to grep and sed all over in order to do
it.

It just feels cleaner and easier.

I know essentially, if you stick to having many classes in a python
module, you have what I referred to in the previous paragraph, because
you can stick to importing other modules at the beginning of a module
and so have them and their contens available in the entire file.

Still, I'm investigating whether I can bend the ever-so-flexible python
to work well with my admittedly somewhat strange requirement.  And, off
course, I'd like to hear what others think.

-i