14

I have this package:

mypackage/
    __init__.py
    a.py
    b.py

And I want to import things from module a to module b, does it make sense to write in module b

from mypackage.a import *

or should I just use

from a import *

Both options will work, I'm just wondering which is better (the 2nd makes sense because it's in the same level but I'm considering the 1st to avoid collisions, for example if the system is running from a folder that contains a file named a.py).

Rod
  • 52,748
  • 3
  • 38
  • 55
banana
  • 143
  • 1
  • 4

2 Answers2

7

You can safely use number 2 because there shouldn't be any collisions - you'll be always importing a module from the same package as the current one. Please note, that if your module has the same name as one of the standard library modules, it will be imported instead of the standard one. From the documentation:

When a module named spam is imported, the interpreter first searches for a built-in module with that name. If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations:

  • the directory containing the input script (or the current directory).
  • PYTHONPATH (a list of directory names, with the same syntax as the
  • shell variable PATH).
  • the installation-dependent default.

After initialization, Python programs can modify sys.path. The directory containing the script being run is placed at the beginning of the search path, ahead of the standard library path. This means that scripts in that directory will be loaded instead of modules of the same name in the library directory. This is an error unless the replacement is intended. See section Standard Modules for more information.

The option from mypackage.a import * can be used for consistency reasons all over the project. In some modules you will have to do absolute imports anyway. Thus you won't have to think whether the module is in the same package or not and simply use a uniform style in the entire project. Additionally this approach is more reliable and predictable.

Python style guidelines don't recommend using relative imports:

Relative imports for intra-package imports are highly discouraged. Always use the absolute package path for all imports. Even now that PEP 328 is fully implemented in Python 2.5, its style of explicit relative imports is actively discouraged; absolute imports are more portable and usually more readable.

Since python 2.5 a new syntax for intra-package relative imports has been introduced. Now you can . to refer to the current module and .. referring to the module being 1 level above.

from . import echo
from .. import formats
from ..filters import equalizer
Maksim Skurydzin
  • 10,301
  • 8
  • 40
  • 53
  • 5
    And how do you know that whatever 'a' really is isn't a collision with a builtin? Implicit relative imports were killed for a reason, they're not safe. – MatthewWilkes Aug 14 '12 at 13:56
  • You are right, a builtin module will simply be masked with the one of our own having the same name. – Maksim Skurydzin Aug 14 '12 at 14:25
  • "Python style guidelines don't recommend the first approach:" To me it looks like they do recommend the 1st "Always use the absolute package path for all imports" – banana Aug 15 '12 at 15:37
  • right, sorry. My head and hands went async. Corrected the answer accordingly. – Maksim Skurydzin Aug 15 '12 at 19:03
5

You should use from mypackage.a import things, you, want.

There are two issues here, the main one is relative vs absolute imports, the semantics of which changed in Python 3, and can optionally be used in Python 2.6 and 2.7 using a __future__ import. By using mypackage.a you guarantee that you will get the code you actually want, and it will work reliably on future versions of Python.

The second thing is that you should avoid import *, as it can potentially mask other code. What if the a.py file gained a function called sum? It would silently override the builtin one. This is especially bad when importing your own code in other modules, as you may well have reused variable or function names.

Therefore, you should only ever import the specific functions you need. Using pyflakes on your sourcecode will then warn you when you have potential conflicts.

MatthewWilkes
  • 1,048
  • 8
  • 15