[Python-Dev] Draft: PEP for imports (original) (raw)

Barry Warsaw barry at python.org
Fri Jan 30 20:15:04 EST 2004

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

More information about the Python-Dev mailing list