import problem

[Steven D'Aprano]

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