Namespace confusion

[Alex Martelli]

"Luna Tic" <lunatic at beyond.net> wrote in message
news:9nssgi$oiv$1 at news.netcologne.de...
    ...
> I get an error message certainly because of the interdependence of those
> two modules, am I right?

Not really -- you get the error message because
you're trying to append (in bar.bacon.__init__)
to an attribute (list) that you haven't yet bound
in object foo.i.

But.  Cycles of dependency between allegedly separate
parts are an utter disaster in the design of any
system, in any language -- they make a mockery of the
"separation" and turn it into a nightmare instead.

So: the error you made in switching the two statements
in foo.foo.__init__ was a lucky one.  It alerted you
to a deep architectural defect in your design, before
that defect bit too deeply.  Refactor the defect away
NOW -- you'll be glad you did!


> How then can I resolve this issue? Note that I'd like to keep those two
> files separated.

If the components are separated, then you must remove
the mutual dependency.  Managing dependency is as
crucial in software architecture as managing risk
is in finance.  If you don't manage it, if you just
let it happen, you're not architecting software at
all -- just like a bank that's not managing risk is
not a real financial institution at all.

Here, why should classes bar and foo be in separate
modules at all, given that the mutual dependency
makes a mockery of their alleged "separation"?  Put
them into one module, say foo.  If you have some
external constraints (e.g. backwards compatibility)
that force you to let _other_ client code import bar
and access class bar.bacon, just make file bar.py a
compatibility-mandated skeleton which just does
    from foo import bacon
and be done with it...


Alex