software design question

[Josiah Carlson]

> 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.

Design your interface, and write your program around your interface. 
Here's one:

#main
import submodule

class data_storehouse:
     pass

passer = data_storehouse()
passer.error = None
passer.main = main
#etc.

def caller(*args, **kwargs):
     passer.args = args
     passer.kwargs = kwargs

     submodule(passer)
     if passer.error:
         #handle the error


This is essentially another user was doing with their "Singleton()" 
interface, though they created a bottom-level module to hold all 
application-wide information.


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

So you only pass the ones you know about when writing your application. 
  When functionality A gets created, before component B, likely 
functionality A won't require component B.  If you discover later that 
it does, then you modify functionality A to use component B.  You can't 
magically get away from this.


> 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.

Of course it is.  It also doesn't scale very well, though Python 
namespaces (dictionaries) don't seem to have issues with pollution, it 
can get unweidly to handle.


>>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! 

The kludge, no.  That's why I called it a kludge.  You can propagate 
namespaces without a problem, and you don't even have to worry about the 
Python import mechanisms.  It ends up with the same functionality as 
having a single module, without having a single module.


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

I never said it was a good idea.


> 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.

I don't know, I never thought about it, because I never learned Java.  I 
was in the last year they taught C/C++.

Thinking about it now, I think it is a poor language restriction.  Being 
able to have a half-dozen classes with related functionality in a single 
module is /very/ convenient.  Check out the threading or itertools 
modules.  Imagine having to use threading.Thread.Thread or 
itertools.imap.imap, those would be annoying and useless bubbles.

> A <==> B
> 
> Suggestion 1:
> 
> A1 ==> B ==> A2
> A1 ========> A2
> 
> Suggestion 2:
> 
> A2 ==> B2 ==> A1 ==> B1
> A2 =========> A1     B1
>        B2 =========> B1

You can still end up SOL if A1 requires functionality from A2.  You 
still have a circular dependency.  As the sibling reply by John Roth says,
    "this doesn't always work in practice.  Another term for hierarchical
    design is layered architecture. The rule in a layered architecture is
    'call down, notify up.' It's the higherlayer's  esponsibility to call
    down to install callbacks so that the lower layer can notify up at
    run time."

John says the truth.
  - Josiah