[Python-Dev] Draft: PEP for imports

[Barry Warsaw]

On Fri, 2004-01-30 at 18:40, Armin Rigo wrote:

> * 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.)

I don't use path hacks to find data files, but I have gotten into the
habit of making data file directories packages when they live inside the
source tree.  Then I can just do 

from my.package import data
myfile = os.path.join(os.path.dirname(data.__file__), 'myfile.xml')

> * 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".

This is definitely a common idiom.  I call the file path.py and yes,
every top level script must import this before it imports any of the
application's modules.  We've been doing this kind of thing for years,
and while I very often wish there was something we could put in the
standard library, or hack we could add to the executable, there have
really never been any elegant-enough solutions to the problem.

> 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.

Two different things.  Packages are a huge win IMO because it allows for
larger organizing principles.  Flat import space was really painful
before packages came along.  Things like distutils wouldn't be feasible
without them, and we'd be arguing about naming conventions much more if
we didn't have them.

That's aside from the path hackery necessary for top level application
scripts.  I use "from package import module" all the time and I think
Python's rules here are just about right.  Personally, my only complaint
is the default-relative import rule.

> 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 disagree.  I really like the layer of abstraction Python imposes here
and I'd hate to see that taken away.  I'm -1 on any proposal to use
(forward) slashes in import statements.  To me, it's way to system
dependent (wait 'til the Windows people push for backslashes).  I also
like the level of indirection, control, and flexibility that sys.path
gives you.  I agree it would be nice to not have to write autopath.py
modules, but that only affects a handful of files in an otherwise large
application.

Other than relative imports, the only other thing I occasionally miss in
Python's import semantics is the fact that more than one file system
space can't be mapped into one package namespace without trickery.  E.g.
if in "import my.package.sub1" and "import my.package.sub2", the
directories sub1 and sub2 didn't have to live under a directory called
my/package.

> 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.

I disagree that Python's current rules are not natural.  I think they're
very natural, modulo a few nits here and there.  I definitely don't want
to live closer to the metal in the import statement.

-Barry