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

Groups > comp.lang.python > #54196 > unrolled thread

import problem

Back to article view | Back to comp.lang.python

Contents

  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

#54196 — import problem

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
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'
###########################################
When i changed the my code to:
#################################################33
    from  ui.interface.interface import *
    obj = ui.interface.interface.InterfaceCodes()
##############################################3

I get the :

#################################333
raceback (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()
NameError: name 'ui' is not defined
###############################
Also if i delete "ui.interface.interface" i get the :
########################3333
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 = InterfaceCodes()
NameError: name 'InterfaceCodes' is not defined
############################

You make mme happy if help me....
Yours,
Mohsen

[toc] | [next] | [standalone]

#54198

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

[toc] | [prev] | [next] | [standalone]

#54199

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

[toc] | [prev] | [next] | [standalone]

#54202

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
Dear Steven,

I moved all of files to root of source directory, And create an put my
constructor to objects.py file :
#################################
interfaceCodesObj =  interface.InterfaceCodes()
#############################333
And in another files that i import object such as:
######################
from objects import * 
######################
i get the the folloiwing traceback:
####################################3
Traceback (most recent call last):
  File "/home/mohsen/codes/amlak/amlak/src/materialsFindFrame.py", line
187, in <lambda>
    QtCore.QObject.connect(self.checkBox,
QtCore.SIGNAL(_fromUtf8("toggled(bool)")), lambda:
interfaceCodesObj.unSetFilterDict("name"))
NameError: global name 'interfaceCodesObj' is not defined
Traceback (most recent call last):
  File "/home/mohsen/codes/amlak/amlak/src/materialsFindFrame.py", line
192, in <lambda>
    QtCore.QObject.connect(self.checkBox,
QtCore.SIGNAL(_fromUtf8("toggled(bool)")), lambda:
interfaceCodesObj.setFilterDict(self,self.checkBox,"name",self.lineEdit.text()))
NameError: global name 'interfaceCodesObj' is not defined
Traceback (most recent call last):
  File "/home/mohsen/codes/amlak/amlak/src/materialsFindFrame.py", line
198, in <lambda>
    QtCore.QObject.connect(self.checkBox,
QtCore.SIGNAL(_fromUtf8("toggled(bool)")), lambda:
interfaceCodesObj.responseToRequestForData(self))
NameError: global name 'interfaceCodesObj' is not defined 
#######################################################

I'm forced to used wildcard such as from~import  syntax.
you said correctly, i was C++ developer.

Yours,
Mohsen

[toc] | [prev] | [next] | [standalone]

#54203

On Mon, 2013-09-16 at 11:14 +0430, Mohsen Pahlevanzadeh wrote:
> 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
> Dear Steven,
> 
> I moved all of files to root of source directory, And create an put my
> constructor to objects.py file :
> #################################
> interfaceCodesObj =  interface.InterfaceCodes()
> #############################333
> And in another files that i import object such as:
> ######################
> from objects import * 
> ######################
> i get the the folloiwing traceback:
> ####################################3
> Traceback (most recent call last):
>   File "/home/mohsen/codes/amlak/amlak/src/materialsFindFrame.py", line
> 187, in <lambda>
>     QtCore.QObject.connect(self.checkBox,
> QtCore.SIGNAL(_fromUtf8("toggled(bool)")), lambda:
> interfaceCodesObj.unSetFilterDict("name"))
> NameError: global name 'interfaceCodesObj' is not defined
> Traceback (most recent call last):
>   File "/home/mohsen/codes/amlak/amlak/src/materialsFindFrame.py", line
> 192, in <lambda>
>     QtCore.QObject.connect(self.checkBox,
> QtCore.SIGNAL(_fromUtf8("toggled(bool)")), lambda:
> interfaceCodesObj.setFilterDict(self,self.checkBox,"name",self.lineEdit.text()))
> NameError: global name 'interfaceCodesObj' is not defined
> Traceback (most recent call last):
>   File "/home/mohsen/codes/amlak/amlak/src/materialsFindFrame.py", line
> 198, in <lambda>
>     QtCore.QObject.connect(self.checkBox,
> QtCore.SIGNAL(_fromUtf8("toggled(bool)")), lambda:
> interfaceCodesObj.responseToRequestForData(self))
> NameError: global name 'interfaceCodesObj' is not defined 
> #######################################################
> 
> I'm forced to used wildcard such as from~import  syntax.
> you said correctly, i was C++ developer.
> 
> Yours,
> Mohsen
> 
I solved with alias :
import foo as bar

[toc] | [prev] | [next] | [standalone]

#54228

On 16/9/2013 00:05, Mohsen Pahlevanzadeh wrote:

> thank you, you gave me "how to get fish" instead of "fish", it's very
> better.

I'd suggest you make a diagram showing each file and indicate what files
it imports by an arrow.  If any arrows form a circle, you (may) have
recursive imports.

You should try to organize your code so you don't have any loops in the
above diagram.  In reasonable designs, you can do that by factoring out
some of the code into new bubbles.  But if you have too many bubbles
already, that just makes it harder to keep track of.

The recursion can sometimes be debugged more easily by eliminating the
"from xxx import *" forms., which really hides what things you get.
You'll only get those symbols already defined in the particular loop,
(which is generaly the ones defined before its import statment) and you
won't find out about the missing one till you try to use it later.

It can sometimes be mitigated by using from xxx import y1, y2  where you
explicitly define those things before the import statement.

However, both of these require you to have the imports somewhere NOT at
the top of the file.  And that can cause other problems.

Best is to avoid any loops in the diagram.

-- 
DaveA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web