Basic 'import' problem

[Josiah Carlson]

> Yes, this seems logical. It looks like I have some fundamental problems 
> with grasping the philosophy of Python...

Where did you think that Python's philosophy would allow you to do 
circular imports?  It doesn't make sense in /any/ language.


> My application is started from base.py. This file imports many other 
> files (modules) that do different stuff. Base.py references dozens of 
> classes and functions in other modules. After a while, there comes a 
> time when some of these modules need to reference some basic function 
> inluded in base.py. Which means (I thought until now) that I have to 
> include base.py in these files. Or not? Are you saying there is no 
> chance of doing this? Let's forget "import" for now and please explain 
> to me: Is there way to create a Python application consisting of several 
> modules that can freely call and reference stuff in each other? From 
> your answer it seems that the anwer is "no".

Of course you can, but is that really good design?

If the thread were up on google, I'd link it, a thread started with the 
subject of "software design question".

What you want can be done in two ways.  Quoting myself from that thread, 
there's the kludge:

main = someclass()
import sys
sys.modules['external'].main = main


And there's the standard method:

import module1
...

class main:
     def __init__(self, args...):
         self.c1 = module1.class1(args...)
         #where args... is the standard initialization for your class,
         #              and any additional objects/methods that c1 needs
         #              access to.

Pass what is needed.  If you can't pass what is needed when external 
module classes are initialized, then set the attribute later.

c1instance.attribute = value


  - Josiah