Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #54199

Re: import problem

Show key headers only | View raw

thank you, you gave me "how to get fish" instead of "fish", it's very
better.
On Mon, 2013-09-16 at 02:56 +0000, Steven D'Aprano wrote:
> 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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

import problem Mohsen Pahlevanzadeh <mohsen@pahlevanzadeh.org> - 2013-09-16 06:53 +0430
  Re: import problem Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-16 02:56 +0000
    Re: import problem Mohsen Pahlevanzadeh <mohsen@pahlevanzadeh.org> - 2013-09-16 08:35 +0430
    Re: import problem Mohsen Pahlevanzadeh <mohsen@pahlevanzadeh.org> - 2013-09-16 11:14 +0430
    Re: import problem Mohsen Pahlevanzadeh <mohsen@pahlevanzadeh.org> - 2013-09-16 11:26 +0430
    Re: import problem Dave Angel <davea@davea.name> - 2013-09-16 14:08 +0000

csiph-web