Handle circular dependencies in Python modules?

Question

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?

Solution 1

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.

Solution 2

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.

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