[Python-Dev] Draft: PEP for imports

[Armin Rigo]

Hello,

On Fri, Jan 30, 2004 at 09:26:13AM -0500, Jp Calderone wrote:
> >   import neatTricks in "/home/guido/lib/python"      # no package
> >   import package.module in "/home/guido/lib/python"  # package
> >   import foo in "."                                  # relative import
> >   from neatTricks in "../cmds" import a, b, c
> >   s=os.path.join("some", "where"); import foo in s   # expression path
> 
>   An experienced Python programmer could probably use this to some
> advantage, but I think many beginners would use it without realizing it will
> very easily result in a piece of software which is completely
> undistributable.

Point taken.  As far as I can see I believe that the whole module system
problably needs some more in-depth rethinking at some point.  For the beginner
the package system is baffling, and for the advanced user it lacks precise
control over what is imported from where, for the cases where it is really
needed.

[tentative development]

In the multi-directory projects I am familiar with, I've seen two cases:

* a stand-alone application that has to deal with file-system-level
directories anyway to access data files; this uses sys.path hacks all around
to make sure the needed directories are accessible when needed.  It would have
been immediately useful to be able to write "import gamesrv fromdir
'../common'".  It would also have been nice to be able to open a file relative
to the current module.  (In this case relative file and module names are
good.)

* a big package named after the application, in which we try to make all
imports absolute.  This is cleaner apart from the need to setup sys.path
initially from user-runnable scripts that are not at the root (which is the
case of all the test_*.py).  The needed hackery can be nicely isolated in a
file 'autopath.py' that is copied into each directory, so that each user
script starts with "import autopath".

I never find myself using "import package.module" but always "from package
import module".  Actually I still have to be convinced that packages are a
Good Thing.  As far as I am concerned, sys.path hacks are the only case in
which I miss a Python feature sufficiently to have to copy similar custom code
all around my projects.

A more radical point of view is that these sys.path hacks are here not because
of a missing feature, but on the contrary to work around the way Python tries
to isolate me from the "messiness out there" (the file system) by mapping it
into a neat language construct (packages).  Trying to map a user-controlled
structure over another, different one is a receipt for eventual confusion,
however good the design is.

I think I'd prefer to have just a reasonably natural way to talk about modules
-- and files in general -- relative to the current module or the standard
library.  This is only a vague idea, but I believe it would fit better into
(at least my view of) Python's philosophy: keep the language simple by
avoiding abstraction layers that are not "natural", i.e. that do some kind of
remapping of concepts, as opposed to just expose a higher-level view of the
same concepts.


A bientot,

Armin.