[Python-Dev] Relative Package Imports

[M.-A. Lemburg]

Jean-Claude Wippler wrote:
> 
> 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.

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

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

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                   108 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/