Re: import problem
On Mon, 2013-09-16 at 02:56 +, 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
Re: import problem
On Mon, 2013-09-16 at 11:14 +0430, Mohsen Pahlevanzadeh wrote: On Mon, 2013-09-16 at 02:56 +, 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
Re: import problem
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: import problem
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
Re: import problem
thank you, you gave me how to get fish instead of fish, it's very better. On Mon, 2013-09-16 at 02:56 +, 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 --
Re: Import Problem on WIndows py3
On 9/4/12 9:49 AM, jimmyli1...@gmail.com wrote: I have a main program and a 3rd party module. Trying to import colorama, where colorama is a folder with files in it, returns an ImportError: No module named colorama. How should I import folders? Do you have a (empty) __init__.py file present in this particular directory? Werner -- http://mail.python.org/mailman/listinfo/python-list
Re: Import Problem on WIndows py3
On Tuesday, September 4, 2012 1:45:55 PM UTC-7, Werner Thie wrote: On 9/4/12 9:49 AM, jimmyli1528 wrote: I have a main program and a 3rd party module. Trying to import colorama, where colorama is a folder with files in it, returns an ImportError: No module named colorama. How should I import folders? Do you have a (empty) __init__.py file present in this particular directory? Werner OK works perfectly! -- http://mail.python.org/mailman/listinfo/python-list
Re: Import problem
News123 wrote:
Jean-Michel Pichavant wrote:
Johny wrote:
I have this directory structure
C:
\A
__init__.py
amodule.py
\B
__init__.py
bmodule.py
\D
__init__.py
dmodule.py
and I want to import bmodule.py
C:\cd \
C:\python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
from A.B import bmodule
I am bmodule
C:\
so far so good. Now I would like to import bmodule but if the current
directory is \D subdirectory.
C: cd \A\B\D
C:\A\B\D
C:\A\B\Dpython
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
import sys
sys.path.append('C:\\A')
from A.B import bmodule
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named A.B
C:\
so I can not import a module from the parent directory? Or where did I
make an error?
Thanks for help
L.
try
import sys
sys.path.append('C:\\')
from A.B import bmodule
is there any 'automatic' way of finding the top level
directory?basically the 'top level directory is the first directory
going upwards, that doesn't contain a __init__.py file.
what if some user has an __init__.py file the top level directory of
your package ?
of course you could do this 'manually' by
doing:
# assume, that this module is A.amodule
import sys
import os
# I'd love to have a similiar automatic construct
if __name__ == __main__:
level = 1 # or function locating how far to go up before
# finding a dir, whcih does not contain a __init__.py
mydir = os.path.split(__file__)[0]
topdir = os.path.join( mydir,*((..,)*level))
abstop = os.path.abspath(topdir)
sys.path.append(abstop)
## now you can import with the normal module paths
import A.blo
print and I found blo,dir(A.blo)
bye N
You don't want to do that and you don't need it neither. That's what the
env variable PYTHONPATH is for. set it correctly, install your package
inside and everything works just fine (+standard). With a linux OS it
easy to create smb links to point to any working directory. It should be
possible on windows as well.
If your package is meant to be destributed, you may use setup.py
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: Import problem
Hi JM,
Jean-Michel Pichavant wrote:
News123 wrote:
Jean-Michel Pichavant wrote:
Johny wrote:
I have this directory structure
C:
\A
__init__.py
amodule.py
\B
__init__.py
bmodule.py
\D
__init__.py
dmodule.py
and I want to import bmodule.py
C:\cd \
C:\python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
from A.B import bmodule
I am bmodule
C:\
so far so good. Now I would like to import bmodule but if the current
directory is \D subdirectory.
C: cd \A\B\D
C:\A\B\D
C:\A\B\Dpython
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
import sys
sys.path.append('C:\\A')
from A.B import bmodule
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named A.B
C:\
so I can not import a module from the parent directory? Or where did I
make an error?
Thanks for help
L.
try
import sys
sys.path.append('C:\\')
from A.B import bmodule
is there any 'automatic' way of finding the top level
directory?basically the 'top level directory is the first directory
going upwards, that doesn't contain a __init__.py file.
what if some user has an __init__.py file the top level directory of
your package ?
Is there any other usage of __init.py__ than indicating a module directory?
I wasn't aware of it, but you're right I did not investigte in depth and
users can of course do whatever they like.
of course you could do this 'manually' by
doing:
# assume, that this module is A.amodule
import sys
import os
# I'd love to have a similiar automatic construct
if __name__ == __main__:
level = 1 # or function locating how far to go up before
# finding a dir, whcih does not contain a __init__.py
mydir = os.path.split(__file__)[0]
topdir = os.path.join( mydir,*((..,)*level))
abstop = os.path.abspath(topdir)
sys.path.append(abstop)
## now you can import with the normal module paths
import A.blo
print and I found blo,dir(A.blo)
You don't want to do that and you don't need it neither. That's what the
env variable PYTHONPATH is for. set it correctly, install your package
inside and everything works just fine (+standard). With a linux OS it
easy to create smb links to point to any working directory. It should be
possible on windows as well.
I like your idea with the symlinks.
However not sure how to do it with windows.
I assume default shortcuts won't do.
If your package is meant to be destributed, you may use setup.py
Well,
It's nice if a user just unpacks a zip file and can click on any script
with the .py suffix in the tree.
(Its nice for example for tutorials / demos )
It's also nice if he can later on just delete the unpacked directory and
there will be no trace left in the registry or in the python base dir.
This is why I'm interested in solutions without setup.py or changing
environment variables.
bye
N
--
http://mail.python.org/mailman/listinfo/python-list
Re: Import problem
Hi JM,
Jean-Michel Pichavant wrote:
News123 wrote:
Jean-Michel Pichavant wrote:
Johny wrote:
I have this directory structure
C:
\A
__init__.py
amodule.py
\B
__init__.py
bmodule.py
\D
__init__.py
dmodule.py
and I want to import bmodule.py
C:\cd \
C:\python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
from A.B import bmodule
I am bmodule
C:\
so far so good. Now I would like to import bmodule but if the current
directory is \D subdirectory.
C: cd \A\B\D
C:\A\B\D
C:\A\B\Dpython
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
import sys
sys.path.append('C:\\A')
from A.B import bmodule
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named A.B
C:\
so I can not import a module from the parent directory? Or where did I
make an error?
Thanks for help
L.
try
import sys
sys.path.append('C:\\')
from A.B import bmodule
is there any 'automatic' way of finding the top level
directory?basically the 'top level directory is the first directory
going upwards, that doesn't contain a __init__.py file.
what if some user has an __init__.py file the top level directory of
your package ?
Is there any other usage of __init.py__ than indicating a module directory?
I wasn't aware of it, but you're right I did not investigte in depth and
users can of course do whatever they like.
of course you could do this 'manually' by
doing:
# assume, that this module is A.amodule
import sys
import os
# I'd love to have a similiar automatic construct
if __name__ == __main__:
level = 1 # or function locating how far to go up before
# finding a dir, whcih does not contain a __init__.py
mydir = os.path.split(__file__)[0]
topdir = os.path.join( mydir,*((..,)*level))
abstop = os.path.abspath(topdir)
sys.path.append(abstop)
## now you can import with the normal module paths
import A.blo
print and I found blo,dir(A.blo)
You don't want to do that and you don't need it neither. That's what the
env variable PYTHONPATH is for. set it correctly, install your package
inside and everything works just fine (+standard). With a linux OS it
easy to create smb links to point to any working directory. It should be
possible on windows as well.
I like your idea with the symlinks.
However not sure how to do it with windows.
I assume default shortcuts won't do.
If your package is meant to be destributed, you may use setup.py
Well,
It's nice if a user just unpacks a zip file and can click on any script
with the .py suffix in the tree.
(Its nice for example for tutorials / demos )
It's also nice if he can later on just delete the unpacked directory and
there will be no trace left in the registry or in the python base dir.
This is why I'm interested in solutions without setup.py or changing
environment variables.
bye
N
--
http://mail.python.org/mailman/listinfo/python-list
Re: Import problem
Johny wrote:
I have this directory structure
C:
\A
__init__.py
amodule.py
\B
__init__.py
bmodule.py
\D
__init__.py
dmodule.py
and I want to import bmodule.py
C:\cd \
C:\python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
from A.B import bmodule
I am bmodule
C:\
so far so good. Now I would like to import bmodule but if the current
directory is \D subdirectory.
C: cd \A\B\D
C:\A\B\D
C:\A\B\Dpython
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
import sys
sys.path.append('C:\\A')
from A.B import bmodule
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named A.B
C:\
so I can not import a module from the parent directory? Or where did I
make an error?
Thanks for help
L.
try
import sys
sys.path.append('C:\\')
from A.B import bmodule
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: Import problem
Hi Steven,
Steven D'Aprano wrote:
On Sat, 06 Mar 2010 03:53:53 -0800, Johny wrote:
import sys
sys.path.append('C:\\A')
from A.B import bmodule
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named A.B
The current directory is irrelevant, except that it is automatically
added to the PYTHONPATH. That's why you can import A.B when the current
directory is C.
Minor currection:
It doesn't seem to be the current directory, but the directory, where
the script is located in, which is auto-appended to the pythonpath
Please see following example:
$ python -V
Python 2.6.4
$ mkdir A
$ touch A/__init__
$ # create A/blla.py an A/blo.py
$ cat A/bla.py
print I am bla
import A.blo
print and I found blo,dir(A.blo)
$ cat A/blo.py
avar = 3
print I am blo
$ python A/bla.py
I am bla
Traceback (most recent call last):
File A/bla.py, line 2, in module
import A.blo
ImportError: No module named A.blo
However:
$ cat alternative_bla.py
import sys
sys.path.append(.)
print I am bla
import A.blo
print and I found blo,dir(A.blo)
$ python A/alternativ_bla.py
I am bla
I am blo
and I found blo ['__builtins__', '__doc__', '__file__', '__name__',
'__package__', 'avar']
bye N
--
http://mail.python.org/mailman/listinfo/python-list
Re: Import problem
Jean-Michel Pichavant wrote:
Johny wrote:
I have this directory structure
C:
\A
__init__.py
amodule.py
\B
__init__.py
bmodule.py
\D
__init__.py
dmodule.py
and I want to import bmodule.py
C:\cd \
C:\python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
from A.B import bmodule
I am bmodule
C:\
so far so good. Now I would like to import bmodule but if the current
directory is \D subdirectory.
C: cd \A\B\D
C:\A\B\D
C:\A\B\Dpython
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
import sys
sys.path.append('C:\\A')
from A.B import bmodule
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named A.B
C:\
so I can not import a module from the parent directory? Or where did I
make an error?
Thanks for help
L.
try
import sys
sys.path.append('C:\\')
from A.B import bmodule
is there any 'automatic' way of finding the top level
directory?basically the 'top level directory is the first directory
going upwards, that doesn't contain a __init__.py file.
of course you could do this 'manually' by
doing:
# assume, that this module is A.amodule
import sys
import os
# I'd love to have a similiar automatic construct
if __name__ == __main__:
level = 1 # or function locating how far to go up before
# finding a dir, whcih does not contain a __init__.py
mydir = os.path.split(__file__)[0]
topdir = os.path.join( mydir,*((..,)*level))
abstop = os.path.abspath(topdir)
sys.path.append(abstop)
## now you can import with the normal module paths
import A.blo
print and I found blo,dir(A.blo)
bye N
--
http://mail.python.org/mailman/listinfo/python-list
Re: Import problem
Jean-Michel Pichavant wrote:
Johny wrote:
I have this directory structure
C:
\A
__init__.py
amodule.py
\B
__init__.py
bmodule.py
\D
__init__.py
dmodule.py
and I want to import bmodule.py
C:\cd \
C:\python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
from A.B import bmodule
I am bmodule
C:\
so far so good. Now I would like to import bmodule but if the current
directory is \D subdirectory.
C: cd \A\B\D
C:\A\B\D
C:\A\B\Dpython
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
import sys
sys.path.append('C:\\A')
from A.B import bmodule
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named A.B
C:\
so I can not import a module from the parent directory? Or where did I
make an error?
Thanks for help
L.
try
import sys
sys.path.append('C:\\')
from A.B import bmodule
is there any 'automatic' way of finding the top level
directory?basically the 'top level directory is the first directory
going upwards, that doesn't contain a __init__.py file.
of course you could do this 'manually' by
doing:
# assume, that this module is A.amodule
import sys
import os
# I'd love to have a similiar automatic construct
if __name__ == __main__:
level = 1 # or function locating how far to go up before
# finding a dir, whcih does not contain a __init__.py
mydir = os.path.split(__file__)[0]
topdir = os.path.join( mydir,*((..,)*level))
abstop = os.path.abspath(topdir)
sys.path.append(abstop)
## now you can import with the normal module paths
import A.blo
print and I found blo,dir(A.blo)
bye N
--
http://mail.python.org/mailman/listinfo/python-list
Re: Import problem
On Sat, 06 Mar 2010 03:53:53 -0800, Johny wrote:
import sys
sys.path.append('C:\\A')
from A.B import bmodule
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named A.B
The current directory is irrelevant, except that it is automatically
added to the PYTHONPATH. That's why you can import A.B when the current
directory is C.
You are trying to import module B from package A *inside* directory C:\A,
but there is no such package A inside C:\A. You need to add C to the
path, and then it should work.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Import Problem
On Sun, Dec 20, 2009 at 3:34 AM, Victor Subervi victorsube...@gmail.com wrote: snip But I get this error: /var/www/html/angrynates.com/cart/createTables2.py 263 /html 264 ''' 265 266 createTables2() 267 createTables2 = function createTables2 /var/www/html/angrynates.com/cart/createTables2.py in createTables2() 105 these.append(basic) 106 i = 0 107 specialtyStore = addStore() 108 addStore = [] Rename this list so its name isn't the same as the addStore() function which you call. For more info, see: http://groups.google.com/group/comp.lang.python/browse_thread/thread/46b4c8af3196caaa?pli=1 109 addStore.append(specialtyStore) specialtyStore undefined, global addStore = function addStore UnboundLocalError: local variable 'addStore' referenced before assignment args = (local variable 'addStore' referenced before assignment,) Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: import problem in tkinter
Jebegnana das wrote: import _tkinter # If this fails your Python may not be configured for Tk I'm using python3 in linux. In windows tkinter is working fine but in mandriva linux spring 2009 it fails to import. Can you please tell me step-by-step on how to fix this issue? In python3.1 home page the description is not clear or it can't be understood by the beginner. As i'm a beginner for programming python in linux please help me out. I want to know what is the thing i missed during installation. I've done the things correctly as mentioned in the python readme text inside the python3.1 tarball file. While searching the net i found out that if i want to fix this issue i've to uninstall and install it again. what should i do now? With Regards, Jebagnana Das.A, Mob : +91-9843828383 Now, send attachments up to 25MB with Yahoo! India Mail. Learn how. http://in.overview.mail.yahoo.com/photos Is the working Windows version the same, or is it 2.x ? The import name for tkinter changed from Tkinter in 2.x to tkinter in 3.x. I don't think you ever need to import _tkinter directly. If you've tried import tkinter and it fails in Python 3.x, then the next thing to do is look in the install directory. For 3.x, in the Lib directory, look for a subdirectory called tkinter. If it's there, and if it contains the file __init__.py, then tkinter is supposedly installed. If it's really a Linux problem, I can't help further. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Import Problem - Please help
On Sep 7, 5:40 pm, newb.py seanm...@gmail.com wrote: I am trying to learn NLP with Python and am getting the following error when trying to do an import statement: import nltk import re from nltk_lite.utilities import re_show Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named nltk_lite.utilities I have installed nltk already and have a problem where I need to remove vowels from text. I think I need this module to complete it. Any help would be much appreciated. Thanks. My version of Python is 2.6.2. It seems that might make a difference here, but I can't figure it out. Again, any help would be fantastic. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Import Problem - Please help
In article 8119a298-4660-4680-b460-0924c9baa...@e4g2000prn.googlegroups.com, newb.py seanm...@gmail.com wrote: On Sep 7, 5:40 pm, newb.py seanm...@gmail.com wrote: I am trying to learn NLP with Python and am getting the following error when trying to do an import statement: import nltk import re from nltk_lite.utilities import re_show Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named nltk_lite.utilities Guessing from the current documentation, try replacing the third line with: from nltk.util import re_show -- Ned Deily, n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Import Problem - Please help
On Sep 7, 6:55 pm, Ned Deily n...@acm.org wrote: In article 8119a298-4660-4680-b460-0924c9baa...@e4g2000prn.googlegroups.com, newb.py seanm...@gmail.com wrote: On Sep 7, 5:40 pm, newb.py seanm...@gmail.com wrote: I am trying to learn NLP with Python and am getting the following error when trying to do an import statement: import nltk import re from nltk_lite.utilities import re_show Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named nltk_lite.utilities Guessing from the current documentation, try replacing the third line with: from nltk.util import re_show -- Ned Deily, n...@acm.org Fantastic. Thanks so much! -- http://mail.python.org/mailman/listinfo/python-list
