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

[Bernhard Herzog]

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/