8

this is a case again where I'm running around in circles and I'm about to go wild.

I wish Python would analyze all files at first, so that it would know all identifiers from the beginning (I think like Java does).

I have a "main.py" and a "gui.py". Every file contains a class, that makes use of the class in the other file. When I try to run "main.py", the interpreter imports "gui", then in "gui.py" it imports "main", then it processes the whole main module and says: "Tee-hee, there is no class with the given name in gui.py."

How can I handle circular dependencies in Python with minimum fuss?

John Y
  • 14,123
  • 2
  • 48
  • 72
rynd
  • 1,865
  • 5
  • 22
  • 24

3 Answers3

17

I thought I'd expand this into an answer instead of a comment.

It's worth noting that circular imports are generally a sign of bad design: instead of demanding the language suit your design, why not change that design?

There are ways around this problem in python:

  • The good option: Refactor your code not to use circular imports.
  • The bad option: Move one of your import statements to a different scope.

But no, you can't pre-parse files. That's not the way Python works, and if you look into how Python works, it's pretty obvious why.

Community
  • 1
  • 1
Gareth Latty
  • 86,389
  • 17
  • 178
  • 183
  • Thanks y'all. Things are a little clearer to me, now. It's like the observer pattern: One class is the guardian of the other (structural, contentual the other way round). The class with less overview just says to registrated listeners: "Um, excuse me, I have changed." I overlooked that in "main.py" I had to distinguish between code for the application logic class and code that first gets the program to run. I have put one import under the class and above the freestanding code. – rynd Apr 11 '12 at 21:02
  • Moving the import to the end of the file doesn't work. If it gets created anywhere in module scope, it will trigger a circular import. Moving the import to a different scope will fix the problem (see my answer below) – jcdyer Apr 11 '12 at 21:09
  • @jcdyer Corrected, and +1 to your answer for giving more detail in that case. – Gareth Latty Apr 11 '12 at 23:01
  • 4
    In an ORM style model where ObjectA has many ObjectB's and ObjectB belongs to ObjectA. That's a common cyclic dependency which seems to make total sense. Is there good way to remove that dependency from the design? – Zac Witte Nov 09 '13 at 18:54
  • @ZacWitte Option 2 - move the cyclical import somewhere where it is only executed after the first import has completed. – Gareth Latty Nov 10 '13 at 11:15
  • Thank you. I was using `from . import stuff` notation, which refuses to allow circular imports at all. But putting the import inside the methods that use it works around that. – Jack O'Connor Jan 14 '15 at 17:01
7

If you can't avoid circular imports, move one of the imports out of module-level scope, and into the method/function where it was used.

filea.py

import fileb

def filea_thing():
    return "Hello"

def other_thing():
    return fileb_thing()[:10]

fileb.py

def fileb_thing():
    import filea
    return filea.filea_thing() + " everyone."

That way, filea will only get imported when you call fileb_thing(), and then it reimports fileb, but since fileb_thing doesn't get called at that point, you don't keep looping around.

As others have pointed out, this is a code smell, but sometimes you need to get something done even if it's ugly.

jcdyer
  • 18,616
  • 5
  • 42
  • 49
3

In general, dependencies should be a tree. Circular dependencies are not resolvable.

The usual way to solve this, though, is to do a "local import" of the required module at a level other than the global namespace.

bukzor
  • 37,539
  • 11
  • 77
  • 111