[Python-Dev] Relative Package Imports
Tue, 14 Sep 1999 10:49:52 +0200
Jean-Claude Wippler wrote:
> > BTW, would you want to miss relative file name paths ?
> Well, that thought did cross my mind while posting that reply...
> I'm not sure. Yes, they are convenient, but "current working directory"
> is not always a pleasant concept (yet more global state - think of tree
> walks and the inconvenience of having to get, alter, work, restore it -
> when using chdir to implement this). I don't use .. as often as might
> be expected. I use "cd ~/something" a lot more. While that may look
> relative at another level, it really is not (as "echo ~" shows). It
> does illustrate how nearly equivalent the two approaches are.
> DOS/Windows has always had a broken relative path: the current drive.
> And the "hash/bang" headers of Unix seem to always use absolute paths.
...and people have turned to /usr/bin/env to get around this necessity
> Some of this may seem to point to the need for relative paths. But I
> think it hides a more fundamental issue: you need to find out context.
> Once you do, relativeness no longer matters (obviously). A system which
> has a current directory and ".." is equivalent to one which has no such
> thing and passes a "starting directory" in the environment, say.
> I think a system with less global state is more modular -> preferable.
Agreed. I would much prefer imputil.py to become a standard -- then I
could add my hook into its chain and wouldn't have to argue for
using relative imports ;-) But then, how would I tell if someone
else already has integrated such a hook in the chain ? I sure wouldn't
want to add another one just to make sure...
If the standard mechanism already knows about '__' then I wouldn't
have to worry.
> Another angle: I have built many types of tree structures, still do.
> Less and less of those contain a "parent" link. Instead of storing a
> parent you can just as easily keep state while descending into children.
> - Unix file info does not maintain a parent directory, it's redundant.
> - Directories do, and file system mount points are messy because of it.
> - Afaik, it's considered bad style to use "../header.h" in C includes.
> - Upward pointers can introduce cycles (no not here, as has been said).
> - In C++, member objects rarely need pointers to the enclosing object.
Note that my patch does exactly this: it resolves the __ while
descending into the package structure -- without any explicit
back reference stored in the modules.
> It is not for a module to know where it "is" in a hierarchy, it is for a
> parent to (sometimes) provide that reference when it uses the module.
> If you want want access to a module called mx, and there may be many of
> them - then you ask another module to locate it for you. One which is
> able to choose / decide for you. Proximity may be a good discriminator,
> but the decision of proximity was not taken by you - and you won't know
> what rule is best. So you ask an "importer" (which could well always be
> the standard Python mechanism). Given the task to write such as beast,
> I'd probably want to implement the following module search as default:
> - look for the module first in the parent (i.e. as sibling)
> - move one level up, look again, etc
> - all the way to the top
> That's just one way to do it - proximity is not *always* what you want.
Now this is an interesting idea... looks like acquisition at the
module import level. Right now the scheme is as follows:
- look for the module in the import module's dir
- look for the module on the PYTHONPATH
You would just add a third lookup step in between the two... it
would cause many more module lookups though.
> So if Zope chooses a different packaging style, let it override import.
> But please don't build ".." into your modules, it doesn't belong there.
> Sorry for all the handwaving generalities. The issues are the same IMO,
> whether relativeness is provided or context, and therefore the outcome
> of this discussion will never be conclusive - they both work.
Y2000: 108 days left
Python Pages: http://www.lemburg.com/python/