On Mon, 16 Sep 2013 06:53:26 +0430, Mohsen Pahlevanzadeh wrote: > Dear all, > > i have the following two line codes: > ############################ > import ui.interface.interface > obj = ui.interface.interface.InterfaceCodes() > ###########################333 > I have same code in another package and work fine. but i get the : > > #####################################################3
This traceback following suggests that your package is a complete tangled mess of wild card imports. Perhaps I am misreading something, but the following suggests that your package is highly coupled, with strong dependencies between different modules. This is a poor design and will give you many, many problems. As you are already having. Do you understand what I mean when I talk about modules being "highly coupled"? Are you a Java or C++ developer learning Python? Your code suggests to me that you might be. If you are, you should read these to get some ideas of how your Java intuitions will lead you astray in Python: http://dirtsimple.org/2004/12/python-is-not-java.html http://dirtsimple.org/2004/12/java-is-not-python-either.html I assume that everything under the "amlak" directory is your code. Is that correct? Here's the traceback again: > Traceback (most > recent call last): > File "./main.py", line 31, in <module> > from materials.materials import * > File "/home/mohsen/codes/amlak/amlak/src/materials/materials.py", line > 40, in <module> > from ui.interface.interface import * > File "/home/mohsen/codes/amlak/amlak/src/ui/interface/interface.py", > line 32, in <module> > from ui.materialsFrame import * > File "/home/mohsen/codes/amlak/amlak/src/ui/materialsFrame.py", line > 24, in <module> > from ui.materialsFindFrame import * > File "/home/mohsen/codes/amlak/amlak/src/ui/materialsFindFrame.py", > line 14, in <module> > from common.objects.objects import * > File "/home/mohsen/codes/amlak/amlak/src/common/objects/objects.py", > line 28, in <module> > obj = ui.interface.interface.InterfaceCodes() > AttributeError: 'module' object has no attribute 'interface' > ########################################### So your main module does a wild-card import from materials.materials, which does a wild-card import from ui.interface.interface, which does a wild-card import from ui.materialsFrame, which does a wild-card import from ui.materialsFindFrame, which does a wild-card import from common.objects.objects, which requires ui.interface.interface to have already been loaded and imported. But it hasn't been, because it is still being imported. The *immediate* problem is that, in effect, before you can import ui.interface.interface, you need to import ui.interface.interface. Obviously this is going to cause you problems. Google on "recursive imports" to learn about the sorts of problems and how to avoid them. The second problem is that, in general, you should try to avoid wild-card imports. They're not always bad, but they were really invented for use in the interactive interpreter so you can do things like this: from math import * sqrt(42) sin(1.5) Using them inside non-interactive code is not forbidden exactly, but it is frowned upon since it makes understanding your code harder. The third problem is that your code layout looks like you are fighting Python, trying to force it to be something it is not. For starters, if you're writing packages that look like this: ui.interface.interface that's simply poor design for Python. My guess is that you might be following the Java convention of putting exactly one class per source file. That is not the way Python code should be written. Modules should contain all the related classes and functions, at least up to the point that the module becomes so large that it is painful to work with. How large is that? In my opinion, this is getting close to the maximum I personally would be comfortable with: http://hg.python.org/cpython/file/3.3/Lib/decimal.py although some people might be happy with large files. But what is important is that related code should be together in the one file, not split across multiple modules and multiple packages. If you are trying to "future proof" your code, and thinking "today it is small, but one day it will be big and will need to be a package with dozens of modules", that doesn't matter. Don't write the code you think you will need in five years. Write the code you need now. Google "YAGNI" for more. I am sorry that I cannot just give you a simple one-line fix for your error. As far as I can see, the fix is to re-design the package so that it is flatter, with fewer imports, and avoid the recursive import. Good luck! -- Steven -- https://mail.python.org/mailman/listinfo/python-list