[Python-Dev] Relative Package Imports

[Jean-Claude Wippler]

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