ValueError: attempted relative import beyond top-level package

Python 3.xPython Import

Python 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.

  1. 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
  1. 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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionnbroView Question on Stackoverflow
Solution 1 - Python 3.xtyphon04View Answer on Stackoverflow
Solution 2 - Python 3.xJBernardoView Answer on Stackoverflow
Solution 3 - Python 3.xAlex44View Answer on Stackoverflow
Solution 4 - Python 3.xAnil_rockstarView Answer on Stackoverflow
Solution 5 - Python 3.xAnaël LeinertView Answer on Stackoverflow
Solution 6 - Python 3.xMark Z.View Answer on Stackoverflow