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