I have a code that runs in Python 2.7 but not in 3.5 and I can't find the reason. It has to do with importing.
The root folder has a subfolder called s. From the root folder, I am running the script a.py which includes the line from s import *.
In the folder s, there is a file called b.py which has the import line: from c import c
which tries to import the class saved in c.py which is located in the subfolder s as well.
When I run the script a.py from the root folder, I get the ImportError saying "No module named c".
In Python 2.7 this runs without problems. Can someone please suggest what may be the issue and how this should be done differently in Python 3.5?
Implicit imports within packages are not available for Python 3, so to get this to work you will need to use an explicit relative import:
from .s import *
This should work for both Python 2 and Python 3. This also makes your intention more clear that you want to import from a relative package, not an installed package.
Related
So the structure of my directory is
src -- |
a.py
b.py
test -- |
test.py
I have tried everything I could, I am not able to import a.py or b.py inside of test.py in any way
I am running Linux Mint 20.2
I am running Python 3.10.9
I am using venv virtual environment
This what I have tried:
Any time I use relative imports, I get this: ImportError: attempted relative import with no known parent package
Adding init.py to directories did not help
Adding to system path did not help and is not an option, other users will be using it on different OSes, including executable file and so on..
Running python -m is not an option as well
Moving all files to one folder to get rid of the structure is stupid and I am not doing that.
Nothing works, I am losing my head, importing a file from a folder in parallel should not be that complicated
I went through all of the similar questions on this page and nothing helped.
I've had similar problems in the past and thus I've created a new import library: ultraimport
It gives the programmer more control over their imports and allows to do file system based relative and absolute imports.
In your test.py you could then write:
import ultraimport
a = ultraimport('__dir__/../src/a.py')
This will always work, independent of your current working diretory and independent of your sys.path. Also it does not matter how you run your program or if you have an init file.
I have two python files in the same directory. I have also __init__.py file as well. Python version is: 3.9.7
Can't figure out why I can't import the modules.
a.py
def aaa():
print ("test")
b.py
from a import aaa
aaa()
Error:
from a import aaa
ImportError: cannot import name 'aaa' from 'a' (/usr/lib64/python3.9/a.py)
Also it doesn't work:
from .a import aaa
ImportError: attempted relative import with no known parent package
Running it as:
python b.py
I have tried other options but without success.
Update: The same simple code from a import aaa aaa()
without init.py works on python 2.7.
OS:
"Red Hat Enterprise Linux 8.5"
Thanks!
For relative imports in the same folder, use a single .
from .a import aaa
Like Samathingamajig pointed out, you need relative imports.
So, first, change the line in b.py to:
from .a import aaa
You also need to deal with the fact that you now have a package instead of a single module. And Python needs to know how to find your modules.
One way tot deal with that, is to run it using -m. If your Python files are in /some/dir/myproject/, run it as follows:
cd /some/dir
python3 -m myproject.b
Note the namespace dot replacing the directory separator in that last command.
Alternatively, install your package (I recommend learning about packaging but for now you can simply move the myproject directory into one of the directories in sys.path), and then you could have any Python file import myproject.b or run python3 -m myproject.b from any directory.
If you want to have a package that can be used both as a library and a stand-alone application, you could add a __main__.py file with the code to run it as an application. That way python3 -m myproject would run your main project
I met an import error called no module named XX.
my project file is organized as follows:
-------A.py
|
B-----__init__.py wrote: from .C import C
|
C.py
|
D -----__init__.py wrote: from .E import E
|
E.py
In A.py, I need to import class C from C.py. but class C needs to use class E(in E.py)to run
In A.py, I wrote import B.C
In C.py, I wrote import D.E
when I run the test in A.py, it gives the error: No module named 'D'
But if I test C.py, there is no problem at all.
Can anyone tell me why and how to fix it?
When you try to run A.py, it fails because the Python interpreter (the program that runs your Python script) cannot find the D package.
When you run C.py, however, the interpreter does find the D package. This is because the script you are running (C.py) is located in the same directory/folder as the D package.
Detailed explanation found in the Python Docs:
When a module named spam is imported, the interpreter first searches for a built-in module with that name. If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations:
The directory containing the input script (or the current directory when no file is specified).
PYTHONPATH (a list of directory names, with the same syntax as the shell variable PATH).
The installation-dependent default (by convention including a site-packages directory, handled by the site module).
A quick fix would be to use a relative import in C.py:
from .D import E
I am currently running on python 3.6 on anaconda. I have a project structure where (test/lib/yolo/yolo_model.py) and (test/car/detection/cpu_yolo_detector.py).
I run my main from the test directory. My main now calls the script cpu_yolo_detector.py from withing (test/car/detection).
From cpu_yolo_detector.py I want to access the yolo_model.py with
"from lib.yolo.yolo_model import YoloModel"
but I get "no module named lib.yolo".
At the beginning of the main.py I add ('C:\\Users\\Name\\Desktop\\test\\lib\\yolo') to the sys.path and I still get that Error.
I tried both python 3.6 and 3.7 aswell as a virtual environment and without a virtual environment. If I run it with PyCharm everything seems to work but from the terminal it doesn't.
It appears test/ is the root of your project structure. If you want
from lib.yolo.yolo_model import YoloModel
to work, then the directory containing lib/ must be in sys.path.
Try adding 'C:\\Users\\Name\\Desktop\\test' to sys.path.
Try to put the two files (module and main file) in the same directory. If the module name is helpermodule
on main write:
import helpermodule
#or import a specific class/method you might need
I'm trying to install LLDB-3.5 on my system, and I'm having incredibly difficult time getting the python2.7 binding modules to load.
The module has the usual structure
/ LLDB
+ __init__.py
+ some_file.py
+ _lldb.so
/ subdirectory
I've verified that path to the module is in PYTHONPATH. I've checked the results of sys.path, its there, and I can directly import some_file.py
import some_file # This line compiles happily.
Weirdly, I can also import init.py
import __init__ # This line complains its missing module lldb.some_file
I did have lldb-3.4 installed, but if I add a print statement in that file, it displays, so I'm definitely looking at this file.
However, when I try to import lldb, I get back
import lldb # ImportError: No module named lldb
I don't understand that.
It's a swig'ed Python wrapper to LLDB, but I've verified that the .so loads. calling "ldd _lldb.so" on the command line shows a good list of resolved dependencies. If I run the commands in init.py in the python shell, (ie, the calls to imp.find_module & imp.load_module) then the so file is loaded happily.
I'm sure this is a very basic issue, but I'm don't use Python much. I've do have virtualenv installed with Python 2.6, but I have of course verified I'm in the right version of Python.
Is the lldb directory itself on the path? For a package, you should have its containing directory (the parent directory of lldb) on sys.path.
(Normally I would expect the package installation to do this for you. However, the note at the very end of this page suggests that they're targeting the use case where you use the Python lldb module from within the lldb command-line program. So you have to set up the path manually.)