ascenator ascenator - 1 month ago 14
Python Question

Python imports relative path

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

Example structure:


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


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?

Any input is highly appreciated :)


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

from mydir.myfile import MySampleClass

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

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