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]

On Tue, 01 Jul 2003 15:36:11 -0700, jinal jhaveri wrote:

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.

--
\ "I'm beginning to think that life is just one long Yoko Ono |
`\ album; no rhyme or reason, just a lot of incoherent shrieks and |
_o__) then it's over." -- Ian Wolff |
http://bignose.squidly.org/ 9CFE12B0 791A4267 887F520C B7AC2E51 BD41714B

[John Roth]

"jinal jhaveri" <jh*****@usc.edu> wrote in message
news:ma**********************************@python.o rg...

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


thank you
Jinal

[Ian Bicking]

On Tue, 2003-07-01 at 19:00, Ben Finney wrote:

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]

"Ian Bicking" <ia**@colorstudy.com> wrote in message
news:ma**********************************@python.o rg...

On Tue, 2003-07-01 at 19:00, Ben Finney wrote:

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

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.
And circular dependencies are difficult as well. The best policy,
as several posters have already said, is to redesign to eliminate it.

John Roth
Ian

[Aahz]

In article <ma**********************************@python.org >,
Ian Bicking <ia**@colorstudy.com> wrote:

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.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

If you're familiar with the song "Woad", try reading the Subject: line
again. ;-)

[Aahz]

In article <ma**********************************@python.org >,
Ian Bicking <ia**@colorstudy.com> wrote:

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.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

If you're familiar with the song "Woad", try reading the Subject: line
again. ;-)

[Ian Bicking]

On Wed, 2003-07-02 at 10:03, Aahz wrote:

In article <ma**********************************@python.org >,
Ian Bicking <ia**@colorstudy.com> wrote:

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.

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

[Aahz]

In article <ma*********************************@python.org> ,
Ian Bicking <ia**@colorstudy.com> wrote:

On Wed, 2003-07-02 at 10:03, Aahz wrote:

In article <ma**********************************@python.org >,
Ian Bicking <ia**@colorstudy.com> wrote:

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.

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.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

Usenet is not a democracy. It is a weird cross between an anarchy and a
dictatorship.

[Bob Gailer]

At 02:43 PM 7/2/2003 -0500, Ian Bicking wrote:

On Wed, 2003-07-02 at 10:03, Aahz wrote:

In article <ma**********************************@python.org >,
Ian Bicking <ia**@colorstudy.com> wrote:

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.

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
bg*****@alum.rpi.edu
303 442 2625
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.492 / Virus Database: 291 - Release Date: 6/24/2003

[Ian Bicking]

On Wed, 2003-07-02 at 10:03, Aahz wrote:

In article <ma**********************************@python.org >,
Ian Bicking <ia**@colorstudy.com> wrote:

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.

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

[Aahz]

In article <ma*********************************@python.org> ,
Ian Bicking <ia**@colorstudy.com> wrote:

On Wed, 2003-07-02 at 10:03, Aahz wrote:

In article <ma**********************************@python.org >,
Ian Bicking <ia**@colorstudy.com> wrote:

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.

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.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

Usenet is not a democracy. It is a weird cross between an anarchy and a
dictatorship.

[Bob Gailer]

At 02:43 PM 7/2/2003 -0500, Ian Bicking wrote:

On Wed, 2003-07-02 at 10:03, Aahz wrote:

In article <ma**********************************@python.org >,
Ian Bicking <ia**@colorstudy.com> wrote:

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.

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
bg*****@alum.rpi.edu
303 442 2625
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.492 / Virus Database: 291 - Release Date: 6/24/2003