"Iwan Vosloo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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.
Have you looked at using scons (http://www.scons.org/) instead of make? > 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. Sometimes little conveniences lead to great big tar pits. > 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. This is what packages are for. As far as refactoring package alignments, a little bit of scripting goes a long way. Sometimes trying to make an existing tool do something that it's not really right for distorts the entire process, rather than simplifies it. John Roth > > -i > -- http://mail.python.org/mailman/listinfo/python-list
