import problem
Mohsen Pahlevanzadeh
mohsen at pahlevanzadeh.org
Mon Sep 16 00:05:04 EDT 2013
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
More information about the Python-list
mailing list