PEP 328 update

[Bernhard Herzog]

Aahz <aahz at pythoncraft.com> writes:

> PEP 328 (``import`` changes) has been updated and is available at
> http://www.python.org/peps/pep-0328.html
>
> Comments on the revised version are welcome. 

pep-0328:

   In Python 2.5, any ``import`` statement that results in an
   intra-package import will raise ``DeprecationWarning``

Phrased like that it would seem that absolute imports referring to a
sibling module will be deprecated too :)


> One area where feedback is
> particularly desired is on the frequency of relative imports inside
> packages in current code, both in absolute terms and as a percentage of
> all imports.

A while back I've written a script for this.  Unfortunately, I have had
very little time for Python related things in the last few months and I
never got around to post it or the statistics I gathered with it.  I've
made the script available now at
http://intevation.de/~bh/python/importstat.py

What the script looks at is the relationship between the importing
module and the imported module *regardless of the spelling of the
import*.  The last is important since it means that "import bar" and
"import foo.bar" will be considered the same if they refer to the same
module.  The reason for this is that I wrote it to demonstrate that it
is very common to refer to other modules in the same package or the same
hierarchy.  It shouldn't be hard to modify the script to account for the
spelling as well.


The script distinguishes three kinds of imports:

 - Imports of modules in the same package.  E.g. a.b.c imports a.b.x

 - Imports of modules in the same hierarchy but not the same package
   E.g. a.b.c imports a.x.y

 - absolute imports i.e. imports of modules somewhere else on sys.path.
   E.g. a.b.c imports z


Some typical results
               absolute hierarchy package
email (Py 2.3)     50         0      41   (without email.test)
distutils (2.3)   145        71      70
twisted (1.0.0)   544       439     240   (without 
Skencil (0.6)     199       248     222
Skencil (0.7)     175       318     205
Thuban            134       112     115


It should be clear from that that it's very common for a module in a
package to refer to other modules in the same package or the same
hierarchy.  In the case of my own code, i.e. Skencil and Thuban above,
all package imports are relative imports.


Some more general comments on the pep:

I'd still don't understand why it's better to break backwards
compatibility to solve a problem that rarely occurs instead of staying
compatible by introducing a new spelling for absolute imports for those
few cases where the default behavior picks the wrong module.

In practically all other cases where python has several nested scopes
the local scope is the default and there is special way to refer to
outer scopes.  Examples for this are local variables vs. globals and
builtins, or instance variables vs. class variables.  Why should this be
different for imports?

On the whole, I don't find the pep as bad as I did when I first learned
about it.  It does offer some new possibilities for relative imports and
offers a solution for a rare but real problem.  Still, in my eyes
especially the early versions of the pep are an example of the
carelessness with wich some core python developers toss backwards
compatibility out of the window.  I'm not against breaking compatibility
when it is a clear gain for the language but it never should be done
lightly and should always result in substantial improvements in the
language that would not be possible otherwise.  I don't think that's the
case for this pep, though.

Finally, I think I've found a way to deal with the incompatibilities
that minimizes their impact for me.  While hacking on the importstat
script, it occurred to me that it shouldn't be hard to write an
__import__ hook that implements the old import behavior in such a way
that it could be switched on for specific package hierachies.  I'll
probably end up implementing that once Python 2.5 is about to be
released so that I don't have to change practically every module in
Skencil and Thuban just to keep up with Python incompatibilities.



   Bernhard

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