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