[Tutor] reciprocal import

[Alan Gauld]

"spir" <denis.spir at free.fr> wrote

> Actually, I have 2 main modules that work together to achieve the 
> task.
> In the first one(A) is defined a set of objects that outline the 
> creation
> of objects which classes & subclasses are in the second module(B).

So far so good. A needs to import B but B does not need to import A.

> A third one(C) copes with exceptions -- so it needs to be referenced 
> in
> both other modules.

Again that's OK, both A and B can import C.

> But, in order to provide the user meaning- and help-ful information,
> I need to access some elements from the module that launched
> the exception.

And this is where the design starts to smell bad.
The exceptions should not need to access the raising class,
the raiser should pass information (perhaps the whole object
via self) into the exception. But exceptions are usually fairly dumb
classes - just transporters of information, it's the handlers where
the intelligence should lie. So how is your exception handling 
working?
It should be in the place where the exception is caught.

> Actually, the whole of it forms a unity and can be put in a single 
> file
> -- but isn't this true for any application?

No, most well designed applications are modular in nature and
chunks can be taken out and reused and other chunks from
other apps inserted without undue disturbance. But that does
require thinking carefully about data flow between modules and
the location of responsibilities for processing that data.

HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld