[Python-Dev] Some comments on PEP 328 (absolute/relative imports) (original) (raw)

Bernhard Herzog bh at intevation.de
Sat Apr 3 13:24:24 EST 2004

I have some comments on PEP 328 (absolute/relative imports). A brief summary would be "-1", mostly because it unnecessarily breaks backwards compatibility and will cause extra work just to keep up with Python.

Missing Rationale for the Incompatibility

First of all, I think the rationale for the absolute imports is missing some important points.

From the pep:

In current Python, if you're reading a module located inside a
package, it is not clear whether ::

   import foo

refers to a top-level module or to another module inside the package.

I don't think this is a good description of the actual problem. The problem is that the modules in the package shadow global ones and there's no easy way to bypass the local package. FWIW, though, I don't recall ever running into a problem with that.

To resolve the ambiguity, it is proposed that ``foo`` will always be
a module or package reachable from ``sys.path``.

What I'm missing here is an explanation why this is the proposed solution. From my point of view the problem happens too rarely to justify breaking existing code. It's not even difficult to come up with a backwards compatible solution. In the few cases where a local module shadows a global one, the import could flaged as absolute with the global keyword, for instance (as has been suggested in one of the threads referenced in the pep):

import global time
from global foo import bar

Unlike the proposed solution, this not only retains compatibility, it would also be similar to how conflicts between local and global scopes are handled elsewhere in Python. For instance, local variables hide globals and builtins. If you later need to access a shadowed global you need to e.g. rename your local variables or resort to some other way to get at the global. Why, then should local, i.e. relative, imports not shadow global ones by default unless a globel, i.e. absolute, import is explicitly requested?

Python-Version Independent Code

I like relative imports and it's good to see that the pep proposes to keep them and even to extend their capabilities. However, I also like to write code that runs on a range of Python versions, e.g. 2.2 and later. Unfortunately, if, as is hinted at in the pep, the new syntax becomes the default in 2.5, there will no way to write relative imports that will work in both 2.3 and 2.5. So, for me the pep effectively abolishes relative imports completely. It also means that I will have to go through all my code and change relative imports to absolute imports, costing me at least a few hours that I would rather spend enhancing my code instead of just keeping up with Python.

Deprecation Warnings

Another thing missing is a note about DeprecationWarnings. Since the change will break exisiting code, DeprecationWarnings should be given for relative imports at some point before the new semantics become the default.

Leading Dots

Leading dots were also recently mentioned to be used for a with-statement. Won't two different uses for leading dots be confusing for newbies? E.g. in

with some_object:
.a = 1
from .magic import xyzzy

the leading dot in the import statement won't have anything to do with the with statement. I guess code like the above would be rare, but some people expressed concern about the use of "as" for decorators for similar reasons.

Bernhard

-- Intevation GmbH http://intevation.de/ Skencil http://sketch.sourceforge.net/ Thuban http://thuban.intevation.org/

More information about the Python-Dev mailing list