Circular Inheritance

[jinal jhaveri]

Hi All,

I have one question regarding circular inheritance

I have 3 files

1) A.py , having module A and some other modules
2) B.py having module B and some other modules
3) C.py having module C and some other modules

Now I want to import Module C in B.py

but C requires A.py
and A requires B.py

so

B requires C
C requires A
A requires B

and when I try to do this using

from ...import....
it tells me that you cannot import this.

So any suggestions on this?

thank you
Jinal

 

[Ben Finney]

B requires C
C requires A
A requires B

and when I try to do this using
from ...import....
it tells me that you cannot import this.

Don't Do That Then.

Re-design the modules so that inheritance is a hierarchy. A band-aid
solution may be to create a new class that mediates between two others,
breaking the circle. Much better is to figure out why the classes need
to know so much about each other, and redesign them with smaller,
simpler interfaces.

Even if there were a way to do circular inheritance, it would be a
nightmare to understand, so needs to be redesigned anyway.

 

[John Roth]

Hi All,

I have one question regarding circular inheritance

I have 3 files

1) A.py , having module A and some other modules
2) B.py having module B and some other modules
3) C.py having module C and some other modules

Now I want to import Module C in B.py

but C requires A.py
and A requires B.py

so

B requires C
C requires A
A requires B

and when I try to do this using

from ...import....
it tells me that you cannot import this.

So any suggestions on this?

You've run into one one of those things that is only
understandable if you remember that Python *executes*
the module during the import process.

When you say "import" something, Python suspends
importing the first module, and begins importing the
second.

Then if the second one tries to import the first, it sees
that it's in the module table, and tries to find what you
requested; but it's incomplete since it's stalled at the
first "import" statement so it probably won't find
whatever it was looking for.

The best way around this is to eliminate the circular
dependency. The result is clearer and easier to
maintain.

Otherwise, you have to be very specific about what
goes where in each module so that any resources that
one wants have actually been loaded when the other
executes. In particular, "from foo import *" simply
doesn't work with a circular import. If it's not in
the incomplete module, it won't get imported.

John Roth

 

[Ian Bicking]

Re-design the modules so that inheritance is a hierarchy. A band-aid
solution may be to create a new class that mediates between two others,
breaking the circle. Much better is to figure out why the classes need
to know so much about each other, and redesign them with smaller,
simpler interfaces.

It seems quite reasonable to have circular dependencies between two or
more classes. The most common case being that one class references the
other, and the other class has back references. Very common, and it
doesn't imply that the classes know too much about each other.

You might encounter less problems if those classes go together in a
single module, but module boundaries are just there to help the
programmer organize code, they have little formal meaning.

Even if there were a way to do circular inheritance, it would be a
nightmare to understand, so needs to be redesigned anyway.

He probably just meant circular dependency, since obviously inheritance
doesn't make sense.

Ian

 

[John Roth]

It seems quite reasonable to have circular dependencies between two or
more classes. The most common case being that one class references the
other, and the other class has back references. Very common, and it
doesn't imply that the classes know too much about each other.

However, this wouldn't normally cause import problems. Import
problems are very specific: they are caused by the two modules
referencing classes or identifiers in the other module ***while they
are being loaded***. If all the modules contain are class and
function definitions, and all the class definitions contain is method
definitions, the only possible problems I could see would be the
inheritance part of the class statement, and defaults in the function
and method definitions. Both of these need to be defined at import
time.

Since inheritance is strictly hierarchical, it isn't too difficult to
import in the right order.

You might encounter less problems if those classes go together in a
single module, but module boundaries are just there to help the
programmer organize code, they have little formal meaning.


He probably just meant circular dependency, since obviously inheritance
doesn't make sense.

And circular dependencies are difficult as well. The best policy,
as several posters have already said, is to redesign to eliminate it.

John Roth

 

[Aahz]

You might encounter less problems if those classes go together in a
single module, but module boundaries are just there to help the
programmer organize code, they have little formal meaning.

That's not true. Modules define a namespace, and Python's execution
model makes heavy use of the "global" (read, current module's) namespace
for name resolution.

 

[Ian Bicking]

That's not true. Modules define a namespace, and Python's execution
model makes heavy use of the "global" (read, current module's) namespace
for name resolution.

Certainly modules have considerable *semantics* and effect execution.
But they have little *meaning*. There's all sorts of semantics
associated with classes, but that's incidental to the meaning of a class
-- a class is a set up behaviors common to a kind of object. A module
is just a pile of stuff the programmer likes to keep together. It's
essentially a clerical feature.

Ian

 

[Bob Gailer]

Certainly modules have considerable *semantics* and effect execution.
But they have little *meaning*. There's all sorts of semantics
associated with classes, but that's incidental to the meaning of a class
-- a class is a set up behaviors common to a kind of object. A module
is just a pile of stuff the programmer likes to keep together. It's
essentially a clerical feature.

Reminds me of the question: "What's the function of mortar." Most will say
"To hold bricks together." But it ALSO keeps them apart!

I prefer to think of modules as a tool to keep various parts of a complex
application apart, rather than having all of them in one module. This
improves readability, maintenance and testing.

Bob Gailer
(e-mail address removed)
303 442 2625

 

[Aahz]

Certainly modules have considerable *semantics* and effect execution.
But they have little *meaning*. There's all sorts of semantics
associated with classes, but that's incidental to the meaning of a class
-- a class is a set up behaviors common to a kind of object. A module
is just a pile of stuff the programmer likes to keep together. It's
essentially a clerical feature.

You say that as if the organizing power of clerical work has little
intrinsic meaning. I disagree. It's precisely that organizing power
that lends value.