• Choose a category
• All
• Classic-Fiction

Although absolute imports let you skip package modules, they still rely on other components of sys.path. For one last test, let’s define two string modules of our own. In the following, there is one module by that name in the CWD, one in the package, and another in the standard library:

# test\string.py

print('string' * 8)

# test\pkg\spam.py

from . import string # <== Relative in both 2.6 and 3.0

print(string)

# test\pkg\string.py

print('Ni' * 8)

When we import the string module with relative import syntax, we get the version in the package, as desired:

C:\test> c:\Python30\python # Same result in 2.6

>>> import pkg.spam

NiNiNiNiNiNiNiNi

When absolute syntax is used, though, the module we get varies per version again. 2.6 interprets this as relative to the package, but 3.0 makes it “absolute,” which in this case really just means it skips the package and loads the version relative to the CWD (not the version the standard library):

# test\string.py

print('string' * 8)

# test\pkg\spam.py

import string # <== Relative in 2.6, "absolute" in 3.0: CWD!

print(string)

# test\pkg\string.py

print('Ni' * 8)

C:\test> c:\Python30\python

>>> import pkg.spam

stringstringstringstringstringstringstringstring

C:\test> c:\Python26\python

>>> import pkg.spam

NiNiNiNiNiNiNiNi

As you can see, although packages can explicitly request modules within their own directories, their imports are otherwise still relative to the rest of the normal module search path. In this case, a file in the program using the package hides the standard library module the package may want. All that the change in 3.0 really accomplishes is allowing package code to select files either inside or outside the package (i.e., relatively or absolutely). Because import resolution can depend on an enclosing context that may not be foreseen, absolute imports in 3.0 are not a guarantee of finding a module in the standard library.

Experiment with these examples on your own for more insight. In practice, this is not usually as ad-hoc as it might seem: you can generally structure your imports, search paths, and module names to work the way you wish during development. You should keep in mind, though, that imports in larger systems may depend upon context of use, and the module import protocol is part of a successful library’s design.

* * *

Note

Now that you’ve learned about package-relative imports, also keep in mind that they may not always be your best option. Absolute package imports, relative to a directory on sys.path, are still sometimes preferred over both implicit package-relative imports in Python 2, and explicit package-relative import syntax in both Python 2 and 3.

Package-relative import syntax and Python 3.0’s new absolute import search rules at least require relative imports from a package to be made explicit, and thus easier to understand and maintain. Files that use imports with dots, though, are implicitly bound to a package directory and cannot be used elsewhere without code changes.

Naturally, the extent to which this may impact your modules can vary per package; absolute imports may also require changes when directories are reorganized.

* * *

* * *

Why You Will Care: Module Packages

Now that packages are a standard part of Python, it’s common to see larger third-party extensions shipped as sets of package directories, rather than flat lists of modules. The win32all Windows extensions package for Python, for instance, was one of the first to jump on the package bandwagon. Many of its utility modules reside in packages imported with paths. For instance, to load client-side COM tools, you use a statement like this:

from win32com.client import constants, Dispatch

This line fetches names from the client module of the win32com package (an install subdirectory).

Package imports are also pervasive in code run under the Jython Java-based implementation of Python, because