Python imports relative path

I’ve got a project where I would like to use some python classes located in other directories.

Example structure:

/dir
 +../subdirA
 +../subdirB
 +../mydir

The absolute path varies, because this project is run on different machines.

When my python file with MySampleClass located in /mydir is executed, how do I import OtherClassRoot located in /dir or OtherClassA located in /subdirA?

I tried things like:

from . import MySampleClass as msc

or

from ../ import MySampleClass as msc

but this always fails or gives me error messages like Attempted relative import in non-package

So, whats the right way to relatively import python files?

Answer

You will need an __init__.py in the mydir directory (and it can be empty), then as long as dir is in the sys path, assuming your MySampleClass is in myfile.py and myfile.py is in mydir

from mydir.myfile import MySampleClass

If you want to import top level functions from a file called util.py that reside in subdirA into myfile.py (where your class is), then an __init__.py must be in subdirA and then in myfile.py

from subdirA.util import somefunc, someotherfunc

The same is true of the sys path, that is, you must either start from ‘dir’ or add it. Everything is imported from the top level of the package (usually your project folder).

However, for module testing, where you might run a function from util in the interpreter, if you start from subdirA, you will need to add dir to the sys path, so your imports can resolve.

>>> import sys
>>> sys.path.append('../dir')

but this is a hack and would be preferable to only use from the interactive interpreter when you are testing. You can also add ‘dir’ to your site packages in a pth file.

To use relative imports, you would need a deeper nested folder, like subdirA/subdirofA, then in subdirofA, you could use . to back out (like from .subdirB ). Really, for me, relative imports are somewhat difficult to see the utility. It’s better for me to use direct imports relative to the project directory, but I could see them being useful if you wanted to nest a naive sub package, but again, still better to be explicit than implicit if possible.

also see this

Update for Python 3’s namespace packages. An __init__.py file is no longer required. Some libraries may still reference the file, so it may still be needed for compatibility. For example,

(test-env) machine:~ user$ mkdir new_package
(test-env) machine:~ user$ python
>>> import new_package
>>> new_package.__file__
>>> type(new_package.__file__)
<class 'NoneType'>
>>>
(test-env) machine:~ user$ touch new_package/__init__.py
(test-env) machine:~ user$ python
>>> import new_package
>>> new_package.__file__
'/Users/user/new_package/__init__.py'
>>> type(new_package.__file__)
<class 'str'>
>>>