Relative Import Problems In Python 3

Python imports drive me crazy (my experience with python imports sometime doesn't correspond at all to idiom 'Explicit is better than implicit' :( ): [app] start.py fro

Solution 1:

A better solution for your problem is to put package1 in it's own separate package. Of course then it can't import package2, but then again if it is reusable, why would it?

Solution 2:

Circular imports should be generally avoided, see also this answer to a related question, or this article on effbot.org.

In this case the problem is that you import from . where . is the current package. So all your from . import X imports go through the package’s __init__.py.

You can make your problem a bit more visible, if you explicitely import your modules in the __init__.py and give them another name (and adjust the other imports to use those names of course):

print('Init package1')
from . import module1 as m1
from . import module2 as m2

Now when you are importing m1 in start.py, the package first initializes m1 and comes to the from . import m2 line. At that point, there is no m2 known in __init__.py so you get an import error. If you switch the import statements in __init__.py around (so you load m2 first), then in m2 it finds the from . import m1 line, which fails for the same reason as before.

If you don’t explicitely import the modules in __init__.py something similar still happens in the background. The difference is that you get a less flat structure (as the imports are no longer started from the package only). As such both module1 and module2 get “started” and you get the respective initialization prints.

To make it work, you could do an absolute import in module2. That way you could avoid that the package needs to resolve everything first, and make it reuse the import from start.py (as it has the same import path).

Or even better, you get rid of the circular import at all. It’s generally a sign that your application structure is not so good, if you have circular references.

(I hope my explanation makes any sense, I already had difficulties writing it, but the general idea should be clear, I hope…)

edit

In response to your update; what you are doing there is that you use the full package name to get the reference to the module. This is equivalent (but much more complicated) to the first possible option to make it work; you use an absolute import using the same import path as in start.py.

Solution 3:

Your update emulates what the absolute import does: import package1.module1 if you do it while module1 being imported. If you'd like to use a dynamic parent package name then to import module1 in the module2.py:

importimportlibmodule1= importlib.import_module('.module1', __package__)

---

I need circular imports. A function in module1 asserts that one of its parameter is instance of a class defined in module2 and viceversa.

You could move one the classes to a separate module to resolve the circular dependency or make the import at a function level if you don't want to use absolute imports.

.
├── start.py
#       from package1 import module1
└── package1
    ├── __init__.py
# print("Init package1")#           from . import module1, module2
    ├── c1.py
# print("Init package1.c1")#           class C1:#               pass
    ├── module1.py
# print("Init package1.module1")#           from .c1 import C1#           from .module2 import C2
    └── module2.py
# print("Init package1.module2")#           from .c1 import C1#           class C2:#               pass#           def f():#               from .module1 import C1

Output

Init package1
Init package1.module1
Init package1.c1
Init package1.module2

Another option that might be simpler than refactoring out c1.py is to merge module{1,2}.py into a single common.py. module{1,2}.py make the imports from common in this case.

Solution 4:

module2.py
          import module1

Works too.

Solution 5:

The accepted answer to Circular import dependency in Python makes a good point:

If a depends on c and c depends on a, aren't they actually the same unit then?

You should really examine why you have split a and c into two packages, because either you have some code you should split off into another package (to make them both depend on that new package, but not each other), or you should merge them into one package. — Lasse V. Karlsen♦

Maybe you should consider placing them in the same module. :)