software design question

[Uwe Mayer]

Josiah Carlson wrote:
>  From the sounds of your posts, you want your software to be "modular",
> in that you want have one file for each of the different components, but
> you don't want to spend the time to pass down all the proper references.
>   As a result, you want to have a single global namespace for all of
> your modules, so that you don't have to pass anything down.

Almost. I want to write software from components. I want a simple, yet clear
and effective interface for the components to communicate with eachother.
The components will be dynamically loaded. If available they have to fit
like a piece in a puzzle, if ther're unavailable all related functionality
will be unavailable - *not* raise exceptions or cause program abortion,
etc.

I simply cannot pass all components to all others, because I don't yet know
which components there might be.

Having a single global name space is poor software design. It makes you not
having to think about "inter module communication", because there is none
to take care of, because you can call virtually everything from everywhere.
 
> There is another kludge:
[...]
> I would suggest you just put everything into a single file.  500 lines
> is not that large.  Heck, a few thousand isn't even that bad, as long as
> you pay attention to what you are doing and use an editor with a
> browsable source tree/class heirarchy, and comment liberally.

Wow! You can't seriously suggest this as a software design recommendation! 

Importing the complete namespace from one module into another is exactly
what will cause you fourty hours of debugging code afterwards.

Do you think there is a reason why in Java every class got to be put into
one source file - or is this just a bad language restriction?
Don't get me wrong, I'm not critisizing Python here.

Searching the litherature I found the following on how to model interaction
between modules:

- relations between modules should be hierachial, i.e. non-cyclic

problem with circular dependencies: "nothing works until everything works"

benefits of non circular design: 
1. development and testing step by step is possible, 
2. you can build subsets for
   - use in other systems
   - own re-use

*sandwiching*:

cyclic dependencies may be resolved by refining the modular structure:

A <==> B

Suggestion 1:

A1 ==> B ==> A2
A1 ========> A2

Suggestion 2:

A2 ==> B2 ==> A1 ==> B1
A2 =========> A1     B1
       B2 =========> B1

Ciao
Uwe