ValueError: attempted relative import beyond top-level package
Python 3.xPython ImportPython 3.x Problem Overview
I was playing the the Python's import system in order to understand better how it works, and I encountered another problem. I have the following structure
pkg/
__init__.py
c.py
d.py
subpkg/
__init__.py
a.py
b.py
Inside a.py
I have the following code:
from . import b
from .. import d
And inside c.py
I have the following:
import subpkg.a
Now I receive the following error:
> ValueError: attempted relative import beyond top-level package
But why? How can I solve it? I am running c.py
from the IDLE, and pkg
should be considered a package, since it has the __init__.py
file.
The first import works fine, but it's the following that doesn't work:
from .. import d
Because I am attempting to import something from a parent package, but apparently I cannot, for some weird reason.
Python 3.x Solutions
Solution 1 - Python 3.x
This had me question my insanity.
The problem stems from the confusion that people mistakenly take the relative import as path relative which is not.
Relative imports depend on the location of the file that is run.
This answer goes deeper into explaining how the python modules actually work, but to summarize.
- When a file is loaded, it is given a name:
- If it was loaded as the top-level script (run directly), its name is
__main__
. - If it was loaded as a module (with import), its name is the filename, preceded by the names of any packages/subpackages of which it is a part, separated by dots -
pkg.subpkg.a
- If you do a
from ..
there must be at least 2 dots in the file name.from ...
- 3 dots.
Now comes the funny part.
If you run c.py directly, then it is given the name __main__
and a.py has subpkg.a
.
As per the 2nd statement, you must have at least 2 dots in the name of subpkg.a
to run from ..
inside it.
The fix
Create a new file outside the pkg, say main.py
pkg/
__init__.py
c.py
d.py
subpkg/
__init__.py
a.py
b.py
main.py
Inside main.py
import pkg.c
If we run main.py, it get's the name __main__
, and a.py get's pkg.subpkg.a
. As per the 2nd statement it now has 2 dots in the name and we can do the from ..
One more thing. Now that c.py is loaded as a module, we have to use from to load a.py.
from .subpkg import a
Solution 2 - Python 3.x
Python 3 changed the import system so every time you want a module that is around the one you are working, you need relative imports (unless you mess with PYTHONPATH
or sys.path
).
The correct usage here should be
from .subpkg import a
When you are working with IDLE, you have a totally different environment. Therefore, you could add the current location to your path so imports work again.
try:
sys.path.insert(0, '')
It might be weird, but it is for a greater good
PS: If this last thing do not work -- I don't have an IDLE environment right now -- it is probably because the work directory is set wrong.
Try this answer instead: https://stackoverflow.com/a/17361545/754991
Solution 3 - Python 3.x
I found this solution:
#! /usr/bin/env python
import os
import sys
sys.path.append(os.path.realpath('.'))
from d import *
Solution 4 - Python 3.x
simply adding/creating init.py file in all folders solved the problem.
folder1 -folder2 -file1.py -folder3 -folder4 - file2.py
I wanted to use a method present in file1.py inside file2.py [ basically two levels up]. so I added empty init.py in all folders & subfolders above and used below in file2.py:-
from folder2.file1 import
Solution 5 - Python 3.x
I am thankful for the top answer, but I find the proposed fix a bit unsatisfying. Here is my suggestion : simply add sys.path.append(".") to your main file. This allows to import first level packages without any change to the project architecture. Just drop the previous .. which are not required anymore.
Solution 6 - Python 3.x
typhon04 has an excellent description that helped me understand the problem, but I disagree with his conclusion of creating a dummy main.py outside everything. Given we're relative to c.py the answer would seem to be we simply no longer need "from .." and simply "import d" is sufficient.