• Choose a category
• All
• Classic-Fiction

By Root 1949 0

is taken to be relative in 2.6 but absolute in 3.0, it fails in the latter. That is, 2.6 searches the containing package first, but 3.0 does not. This is the noncompatible behavior you have to be aware of in 3.0:

C:\test> c:\Python26\python

>>> import pkg.spam

99999

C:\test> c:\Python30\python

>>> import pkg.spam

Traceback (most recent call last):

File "", line 1, in

File "pkg\spam.py", line 1, in

import eggs

ImportError: No module named eggs

To make this work in both 2.6 and 3.0, change the first file to use the special relative import syntax, so that its import searches the package directory in 3.0, too:

# test\pkg\spam.py

from . import eggs # <== Use package relative import in 2.6 or 3.0

print(eggs.X)

# test\pkg\eggs.py

X = 99999

import string

print(string)

C:\test> c:\Python26\python

>>> import pkg.spam

99999

C:\test> c:\Python30\python

>>> import pkg.spam

99999

Imports are still relative to the CWD

Notice in the preceding example that the package modules still have access to standard library modules like string. Really, their imports are still relative to the entries on the module search path, even if those entries are relative themselves. If you add a string module to the CWD again, imports in a package will find it there instead of in the standard library. Although you can skip the package directory with an absolute import in 3.0, you still can’t skip the home directory of the program that imports the package:

# test\string.py

print('string' * 8)

# test\pkg\spam.py

from . import eggs

print(eggs.X)

# test\pkg\eggs.py

X = 99999

import string # <== Gets string in CWD, not Python lib!

print(string)

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

>>> import pkg.spam

stringstringstringstringstringstringstringstring

99999

Selecting modules with relative and absolute imports

To show how this applies to imports of standard library modules, reset the package one more time. Get rid of the local string module, and define a new one inside the package itself:

C:\test> del string*

# test\pkg\spam.py

import string # <== Relative in 2.6, absolute in 3.0

print(string)

# test\pkg\string.py

print('Ni' * 8)

Now, which version of the string module you get depends on which Python you use. As before, 3.0 interprets the import in the first file as absolute and skips the package, but 2.6 does not:

C:\test> c:\Python30\python

>>> import pkg.spam

C:\test> c:\Python26\python

>>> import pkg.spam

NiNiNiNiNiNiNiNi

Using relative import syntax in 3.0 forces the package to be searched again, as it is in 2.6—by using absolute or relative import syntax in 3.0, you can either skip or select the package directory explicitly. In fact, this is the use case that the 3.0 model addresses:

# test\pkg\spam.py

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

print(string)

# test\pkg\string.py

print('Ni' * 8)

C:\test> c:\Python30\python

>>> import pkg.spam

NiNiNiNiNiNiNiNi

C:\test> c:\Python26\python

>>> import pkg.spam

NiNiNiNiNiNiNiNi

It’s important to note that relative import syntax is really a binding declaration, not just a preference. If we delete the string.py file in this example, the relative import in spam.py fails in both 3.0 and 2.6, instead of falling back on the standard library’s version of this module (or any other):

# test\pkg\spam.py

from . import string # <== Fails if no string.py here!

C:\test> C:\python30\python

>>> import pkg.spam

...text omitted...

ImportError: cannot import name string

Modules referenced by relative imports must exist in the package directory.

Imports are still relative to the CWD (again)