How to properly use relative or absolute imports in Python modules?

Question

Usage of relative imports in Python has one drawback, you will not be able to run the modules as standalones anymore because you will get an exception: ValueError: Attempted relative import in non-package

# /test.py: just a sample file importing foo module
import foo
...

# /foo/foo.py:
from . import bar
...
if __name__ == "__main__":
   pass

# /foo/bar.py: a submodule of foo, used by foo.py
from . import foo
...
if __name__ == "__main__":
   pass

How should I modify the sample code in order to be able to execute all: test.py, foo.py and bar.py

I'm looking for a solution that works with python 2.6+ (including 3.x).

Answer 1

So far the only solution I found was not to use relative imports at all.

Due to current limitation, I'm wondering when someone is supposed to use relative imports in python.

On all configurations that I used the sys.path contained the current directory as first argument so just use import foo instead of from . import foo because it will do the same.

Answer 2

You could just start 'to run the modules as standalones' in a bit a different way:

Instead of:

python foo/bar.py

Use:

python -mfoo.bar

Of course, the foo/__init__.py file must be present.

Please also note, that you have a circular dependency between foo.py and bar.py – this won't work. I guess it is just a mistake in your example.

Update: it seems it also works perfectly well to use this as the first line of the foo/bar.py:

#!/usr/bin/python -mfoo.bar

Then you can execute the script directly in POSIX systems.

Answer 3

First, I assume you realize what you've written would lead to a circular import issue, because foo imports bar and viceversa; try adding

from foo import bar

to test.py, and you'll see it fails. The example must be changed in order to work.

So, what you're asking is really to fallback to absolute import when relative import fails; in fact, if you're executing foo.py or bar.py as the main module, the other modules will just lie at the root level, and if they share the name with another module on the system which one will be picked depends on the order in sys.path. Since the current dir is usually the first, local modules will be picked if available - i.e., if you've got an 'os.py' file in the current working dir, it'll be picked instead of the builtin one.

A possibile suggestion is:

foo.py

try:
    from . import bar
except ValueError:
    import bar

if __name__ == "__main__":
    pass

bar.py:

if __name__ == "__main__":
    pass

By the way calling scripts from the proper position is usually way better.

python -mfoo.bar

Is probably the best way to go.

python -mfoo.bar

Answer 4

Why not just put the "main" in a different .py file?

Answer 5

Ditch relative imports: you should think of your package namespace as a global one, anyway.

The trick to making this palatable is editing sys.path appropriately. Here is some food for thought:

# one directory up
_root_dir = os.path.dirname(os.path.dirname(os.path.realpath(__file__)))
sys.path.insert(0, _root_dir)for now