Reputation: 113905
First of all, this is very likely not a path issue.
I have a pydev project in eclipse. Here is the directory structure:
Genetic-Framework
| Genetic-Framework
| Genetic
| __init__.py
| GA.py
| crossover.py
| fitness.py
| individual.py
| mutation.py
| population.py
| selection.py
| settings.py
| visualization.py
In GA.py
, I have the following line:
from Genetic import settings, selection, visualization as vis
And yes, Genetic
is in sys.path
. However, I get the following error:
File "/.../Genetic-Framework/Genetic-Framework/Genetic/GA.py", line 17, in <module>
from Genetic import settings, selection, visualization as vis
ImportError: cannot import name settings
However, when I remove settings
from that line, everything else imports just fine.
Interestingly, among the first lines of settings.py
is this:
from Genetic import fitness, selection, mutation, crossover, population, GA
And when I remove GA
from that line, everything seems to import just fine.
Why am I getting this error? Is this some issue with circular imports? How can I fix this?
Upvotes: 2
Views: 4978
Reputation: 526483
Yes, that's an issue with circular imports.
The problem is that when your GA.py
is run, it first tries to import settings
. This means that settings.py
starts getting run, and it immediately tries to import GA
.
However, GA
is already in the process of loading, so GA.py
doesn't get run a second time - instead, settings
just loads the GA
that is already in memory (which is currently mostly empty, because it's still executing its imports).
Thus, things in settings
that try to use things out of GA
fail, because the things they're looking for in GA
haven't been defined yet (because processing of GA.py
hasn't gotten past the imports yet).
This makes the evaluation of settings.py
raise an exception, which manifests as a failure to be imported (because an exception raised during import makes the import fail).
In general, you should try to avoid circular imports in the first place. They often mean that you have really odd dependency structure that will be hard to debug later.
One way to do this is to try to find things that are needed in both modules and break them out into a separate third module that can be shared between the other two - so instead of using A.x in B, and B.y in A, you instead use C.x and C.y in both A and B.
Another thing you can do is to defer usage of something from another module until after all of the imports have finished. In other words, don't try to reference an imported module's contents from top-level code, but instead place it in a class initializer or a function that you can call later on, once all of the imports have finished.
For example, instead of this...
import Foo
class Baz:
top_level_variable = Foo.bar
you can do this:
import Foo
class Baz:
def __init__(self):
self.instance_variable = Foo.bar
Obviously, instance properties are slightly different from class properties, but the idea is to defer actually having to look things up from other modules until after all of the modules finish executing and thus have their contents available. Also note that from Foo import bar
would fail here because that tries to access the contents of Foo
at the time of the import, which is what needs to be avoided.
Upvotes: 4