Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Circular Inheritance

Reply
Thread Tools

Circular Inheritance

 
 
jinal jhaveri
Guest
Posts: n/a
 
      07-01-2003
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



 
Reply With Quote
 
 
 
 
Ben Finney
Guest
Posts: n/a
 
      07-02-2003
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
 
Reply With Quote
 
 
 
 
John Roth
Guest
Posts: n/a
 
      07-02-2003

"jinal jhaveri" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
>
>



 
Reply With Quote
 
Ian Bicking
Guest
Posts: n/a
 
      07-02-2003
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



 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      07-02-2003

"Ian Bicking" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
>
>



 
Reply With Quote
 
Aahz
Guest
Posts: n/a
 
      07-02-2003
In article <(E-Mail Removed)>,
Ian Bicking <(E-Mail Removed)> 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 ((E-Mail Removed)) <*> http://www.pythoncraft.com/

If you're familiar with the song "Woad", try reading the Subject: line
again.
 
Reply With Quote
 
Ian Bicking
Guest
Posts: n/a
 
      07-02-2003
On Wed, 2003-07-02 at 10:03, Aahz wrote:
> In article <(E-Mail Removed)>,
> Ian Bicking <(E-Mail Removed)> 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



 
Reply With Quote
 
Bob Gailer
Guest
Posts: n/a
 
      07-02-2003
At 02:43 PM 7/2/2003 -0500, Ian Bicking wrote:

>On Wed, 2003-07-02 at 10:03, Aahz wrote:
> > In article <(E-Mail Removed)>,
> > Ian Bicking <(E-Mail Removed)> 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
http://www.velocityreviews.com/forums/(E-Mail Removed)
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

 
Reply With Quote
 
Aahz
Guest
Posts: n/a
 
      07-03-2003
In article <(E-Mail Removed)>,
Ian Bicking <(E-Mail Removed)> wrote:
>On Wed, 2003-07-02 at 10:03, Aahz wrote:
>> In article <(E-Mail Removed)>,
>> Ian Bicking <(E-Mail Removed)> 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 ((E-Mail Removed)) <*> http://www.pythoncraft.com/

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

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Interface inheritance vs Implementation inheritance. Daniel Pitts Java 27 02-27-2008 01:37 AM
Private Inheritance and Publice Inheritance karthikbalaguru C++ 9 09-10-2007 01:05 PM
Semi-circular definitions (plus circular references) Kiuhnm C++ 16 01-03-2005 03:49 AM
mul. inheritance & overloading operator new/delete solved by virtual base inheritance? cppsks C++ 0 10-27-2004 07:49 PM
Private access modifier and Inheritance (Inheritance implementation in Java) maxw_cc Java 1 12-21-2003 11:38 AM



Advertisments