Marc-Andre,
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. 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. 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. 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. 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. -- Jean-Claude