Organizing Python Code

[Russell Wallace]

Tres Seaver wrote:
> Just as '#include "kitchensink.h"' reduces maintainability in a
> C/C++ program (where 'kitchensink.h' then #includes all the other
> project headers),

I find it improves maintainability to not have to keep editing the list
of #include or import directives at the top of each source file.

> your strategy is going to cause the future
> maintainer of your code (likely, you!) to take your name in vain
> after chasing down a few obscure buglets which it enables.

What obscure buglets?  The only issue I'm aware of is conflict between
identifiers defined in two or more modules and as far as I'm concerned,
if I have duplicate public identifiers I want to know about it
immediately rather than wait until something _does_ need to access both
of them.  I've never had any problems with this strategy.

Disclaimer: I've never worked on a project with more than a few
programmers or more than ~100,000 lines of code.  The approach I
mentioned may, for all I know, break down on very large projects.  But
in the size range up to 100 KLOC I find it works fine.  What problems do
you see it causing?

-- 
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mailto:rwallace at esatclear.ie
http://www.esatclear.ie/~rwallace