Imagine this directory structure:
app/ __init__.py sub1/ __init__.py mod1.py sub2/ __init__.py mod2.py
I’m coding mod1
, and I need to import something from mod2
. How should I do it?
I tried from ..sub2 import mod2
but I’m getting an “Attempted relative import in non-package”.
I googled around but found only “sys.path
manipulation” hacks. Isn’t there a clean way?
Edit: all my __init__.py
‘s are currently empty
Edit2: I’m trying to do this because sub2 contains classes that are shared across sub packages (sub1
, subX
, etc.).
Edit3: The behaviour I’m looking for is the same as described in PEP 366 (thanks John B)
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Everyone seems to want to tell you what you should be doing rather than just answering the question.
The problem is that you’re running the module as ‘__main__’ by passing the mod1.py as an argument to the interpreter.
From PEP 328:
Relative imports use a module’s __name__ attribute to determine that module’s position in the package hierarchy. If the module’s name does not contain any package information (e.g. it is set to ‘__main__’) then relative imports are resolved as if the module were a top level module, regardless of where the module is actually located on the file system.
In Python 2.6, they’re adding the ability to reference modules relative to the main module. PEP 366 describes the change.
Update: According to Nick Coghlan, the recommended alternative is to run the module inside the package using the -m switch.
Method 2
Here is the solution which works for me:
I do the relative imports as from ..sub2 import mod2
and then, if I want to run mod1.py
then I go to the parent directory of app
and run the module using the python -m switch as python -m app.sub1.mod1
.
The real reason why this problem occurs with relative imports, is that relative imports works by taking the __name__
property of the module. If the module is being directly run, then __name__
is set to __main__
and it doesn’t contain any information about package structure. And, thats why python complains about the relative import in non-package
error.
So, by using the -m switch you provide the package structure information to python, through which it can resolve the relative imports successfully.
I have encountered this problem many times while doing relative imports. And, after reading all the previous answers, I was still not able to figure out how to solve it, in a clean way, without needing to put boilerplate code in all files. (Though some of the comments were really helpful, thanks to @ncoghlan and @XiongChiamiov)
Hope this helps someone who is fighting with relative imports problem, because going through PEP is really not fun.
Method 3
main.py setup.py app/ -> __init__.py package_a/ -> __init__.py module_a.py package_b/ -> __init__.py module_b.py
- You run
python main.py
. main.py
does:import app.package_a.module_a
module_a.py
doesimport app.package_b.module_b
Alternatively 2 or 3 could use: from app.package_a import module_a
That will work as long as you have app
in your PYTHONPATH. main.py
could be anywhere then.
So you write a setup.py
to copy (install) the whole app package and subpackages to the target system’s python folders, and main.py
to target system’s script folders.
Method 4
“Guido views running scripts within a package as an anti-pattern” (rejected
PEP-3122)
I have spent so much time trying to find a solution, reading related posts here on Stack Overflow and saying to myself “there must be a better way!”. Looks like there is not.
Method 5
This is solved 100%:
- app/
- main.py
- settings/
- local_setings.py
Import settings/local_setting.py in app/main.py:
main.py:
import sys sys.path.insert(0, "../settings") try: from local_settings import * except ImportError: print('No Import')
Method 6
explanation of nosklo's
answer with examples
note: all __init__.py
files are empty.
main.py app/ -> __init__.py package_a/ -> __init__.py fun_a.py package_b/ -> __init__.py fun_b.py
app/package_a/fun_a.py
def print_a(): print 'This is a function in dir package_a'
app/package_b/fun_b.py
from app.package_a.fun_a import print_a def print_b(): print 'This is a function in dir package_b' print 'going to call a function in dir package_a' print '-'*30 print_a()
main.py
from app.package_b import fun_b fun_b.print_b()
if you run $ python main.py
it returns:
This is a function in dir package_b going to call a function in dir package_a ------------------------------ This is a function in dir package_a
- main.py does:
from app.package_b import fun_b
- fun_b.py does
from app.package_a.fun_a import print_a
so file in folder package_b
used file in folder package_a
, which is what you want. Right??
Method 7
def import_path(fullpath): """ Import a file with full path specification. Allows one to import from anywhere, something __import__ does not do. """ path, filename = os.path.split(fullpath) filename, ext = os.path.splitext(filename) sys.path.append(path) module = __import__(filename) reload(module) # Might be out of date del sys.path[-1] return module
I’m using this snippet to import modules from paths, hope that helps
Method 8
This is unfortunately a sys.path hack, but it works quite well.
I encountered this problem with another layer: I already had a module of the specified name, but it was the wrong module.
what I wanted to do was the following (the module I was working from was module3):
mymodule __init__.py mymodule1 __init__.py mymodule1_1 mymodule2 __init__.py mymodule2_1 import mymodule.mymodule1.mymodule1_1
Note that I have already installed mymodule, but in my installation I do not have “mymodule1”
and I would get an ImportError because it was trying to import from my installed modules.
I tried to do a sys.path.append, and that didn’t work. What did work was a sys.path.insert
if __name__ == '__main__': sys.path.insert(0, '../..')
So kind of a hack, but got it all to work!
So keep in mind, if you want your decision to override other paths then you need to use sys.path.insert(0, pathname) to get it to work! This was a very frustrating sticking point for me, allot of people say to use the “append” function to sys.path, but that doesn’t work if you already have a module defined (I find it very strange behavior)
Method 9
Let me just put this here for my own reference. I know that it is not good Python code, but I needed a script for a project I was working on and I wanted to put the script in a scripts
directory.
import os.path import sys sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), "..")))
Method 10
As @EvgeniSergeev says in the comments to the OP, you can import code from a .py
file at an arbitrary location with:
import imp foo = imp.load_source('module.name', '/path/to/file.py') foo.MyClass()
This is taken from this SO answer.
Method 11
Take a look at http://docs.python.org/whatsnew/2.5.html#pep-328-absolute-and-relative-imports. You could do
from .mod1 import stuff
Method 12
From Python doc,
In Python 2.5, you can switch import‘s behaviour to absolute imports using a
from __future__ import absolute_import
directive. This absolute- import behaviour will become the default in a future version (probably Python 2.7). Once absolute imports are the default,import string
will always find the standard library’s version. It’s suggested that users should begin using absolute imports as much as possible, so it’s preferable to begin writingfrom pkg import string
in your code
Method 13
I found it’s more easy to set “PYTHONPATH” enviroment variable to the top folder:
bash$ export PYTHONPATH=/PATH/TO/APP
then:
import sub1.func1 #...more import
of course, PYTHONPATH is “global”, but it didn’t raise trouble for me yet.
Method 14
On top of what John B said, it seems like setting the __package__
variable should help, instead of changing __main__
which could screw up other things. But as far as I could test, it doesn’t completely work as it should.
I have the same problem and neither PEP 328 or 366 solve the problem completely, as both, by the end of the day, need the head of the package to be included in sys.path
, as far as I could understand.
I should also mention that I did not find how to format the string that should go into those variables. Is it "package_head.subfolder.module_name"
or what?
Method 15
You have to append the module’s path to PYTHONPATH
:
export PYTHONPATH="${PYTHONPATH}:/path/to/your/module/"
Method 16
This method queries and auto populates the path:
import os
import inspect
currentdir = os.path.dirname(os.path.abspath(inspect.getfile(inspect.currentframe())))
parentdir = os.path.dirname(currentdir)
os.sys.path.insert(1, parentdir)
# print("currentdir = ", currentdir)
# print("parentdir=", parentdir)
Method 17
A hacky way to do it is to append the current directory to the PATH at runtime as follows:
import pathlib import sys sys.path.append(pathlib.Path(__file__).parent.resolve()) import file_to_import # the actual intended import
In contrast to another solution for this question this uses pathlib
instead of os.path
.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0