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]

Re: Circular Inheritance

On Tue, 01 Jul 2003 15:36:11 -0700, jinal jhaveri wrote:[color=blue]
> 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.[/color]

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]

Re: Circular Inheritance


"jinal jhaveri" <jhaveri@usc.ed u> wrote in message
news:mailman.10 57099023.14043. python-list@python.org ...[color=blue]
> 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?[/color]

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

[color=blue]
>
> thank you
> Jinal
>
>
>[/color]

[Ian Bicking]

Re: Circular Inheritance

On Tue, 2003-07-01 at 19:00, Ben Finney wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> Even if there were a way to do circular inheritance, it would be a
> nightmare to understand, so needs to be redesigned anyway.[/color]

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

Ian

[John Roth]

Re: Circular Inheritance


"Ian Bicking" <ianb@colorstud y.com> wrote in message
news:mailman.10 57124943.21695. python-list@python.org ...[color=blue]
> On Tue, 2003-07-01 at 19:00, Ben Finney wrote:[color=green]
> > Re-design the modules so that inheritance is a hierarchy. A[/color][/color]
band-aid[color=blue][color=green]
> > solution may be to create a new class that mediates between two[/color][/color]
others,[color=blue][color=green]
> > breaking the circle. Much better is to figure out why the classes[/color][/color]
need[color=blue][color=green]
> > to know so much about each other, and redesign them with smaller,
> > simpler interfaces.[/color]
>
> It seems quite reasonable to have circular dependencies between two or
> more classes. The most common case being that one class references[/color]
the[color=blue]
> other, and the other class has back references. Very common, and it
> doesn't imply that the classes know too much about each other.[/color]

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.
[color=blue]
> 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.
>[color=green]
> > Even if there were a way to do circular inheritance, it would be a
> > nightmare to understand, so needs to be redesigned anyway.[/color]
>
> He probably just meant circular dependency, since obviously[/color]
inheritance[color=blue]
> doesn't make sense.[/color]

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

John Roth[color=blue]
>
> Ian
>
>
>[/color]

[Aahz]

What's the use of module spaces? (was Re: Circular Inheritance)

In article <mailman.105712 4943.21695.pyth on-list@python.org >,
Ian Bicking <ianb@colorstud y.com> wrote:[color=blue]
>
>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.[/color]

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 (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

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

[Aahz]

What's the use of module spaces? (was Re: Circular Inheritance)

In article <mailman.105712 4943.21695.pyth on-list@python.org >,
Ian Bicking <ianb@colorstud y.com> wrote:[color=blue]
>
>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.[/color]

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 (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

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

[Ian Bicking]

Re: What's the use of module spaces? (was Re: Circular Inheritance)

On Wed, 2003-07-02 at 10:03, Aahz wrote:[color=blue]
> In article <mailman.105712 4943.21695.pyth on-list@python.org >,
> Ian Bicking <ianb@colorstud y.com> wrote:[color=green]
> >
> >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.[/color]
>
> 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.[/color]

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]

Re: What's the use of module spaces? (was Re: Circular Inheritance)

In article <mailman.105717 4985.2375.pytho n-list@python.org >,
Ian Bicking <ianb@colorstud y.com> wrote:[color=blue]
>On Wed, 2003-07-02 at 10:03, Aahz wrote:[color=green]
>> In article <mailman.105712 4943.21695.pyth on-list@python.org >,
>> Ian Bicking <ianb@colorstud y.com> wrote:[color=darkred]
>>>
>>>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.[/color]
>>
>> 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.[/color]
>
>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.[/color]

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 (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

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

[Bob Gailer]

Re: What's the use of module spaces? (was Re: CircularInherit ance)

At 02:43 PM 7/2/2003 -0500, Ian Bicking wrote:
[color=blue]
>On Wed, 2003-07-02 at 10:03, Aahz wrote:[color=green]
> > In article <mailman.105712 4943.21695.pyth on-list@python.org >,
> > Ian Bicking <ianb@colorstud y.com> wrote:[color=darkred]
> > >
> > >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.[/color]
> >
> > 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.[/color]
>
>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.[/color]

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
bgailer@alum.rp i.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]

Re: What's the use of module spaces? (was Re: Circular Inheritance)

On Wed, 2003-07-02 at 10:03, Aahz wrote:[color=blue]
> In article <mailman.105712 4943.21695.pyth on-list@python.org >,
> Ian Bicking <ianb@colorstud y.com> wrote:[color=green]
> >
> >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.[/color]
>
> 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.[/color]

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]

Re: What's the use of module spaces? (was Re: Circular Inheritance)

In article <mailman.105717 4985.2375.pytho n-list@python.org >,
Ian Bicking <ianb@colorstud y.com> wrote:[color=blue]
>On Wed, 2003-07-02 at 10:03, Aahz wrote:[color=green]
>> In article <mailman.105712 4943.21695.pyth on-list@python.org >,
>> Ian Bicking <ianb@colorstud y.com> wrote:[color=darkred]
>>>
>>>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.[/color]
>>
>> 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.[/color]
>
>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.[/color]

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 (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

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

[Bob Gailer]

Re: What's the use of module spaces? (was Re: CircularInherit ance)

At 02:43 PM 7/2/2003 -0500, Ian Bicking wrote:
[color=blue]
>On Wed, 2003-07-02 at 10:03, Aahz wrote:[color=green]
> > In article <mailman.105712 4943.21695.pyth on-list@python.org >,
> > Ian Bicking <ianb@colorstud y.com> wrote:[color=darkred]
> > >
> > >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.[/color]
> >
> > 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.[/color]
>
>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.[/color]

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
bgailer@alum.rp i.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