[Python-Dev] Alternative Approach to Relative Imports

M.-A. Lemburg mal@lemburg.com
Wed, 22 Sep 1999 17:13:06 +0200


Gordon McMillan wrote:
> 
> [M.-A. Lemburg]
> > The current lookup does the following if you want to import
> > a module E from module A.B.C.D:
> >
> > 1. check A.B.C.E
> > 2. check E
> > 3. fail
> >
> > Now instead of failing we could add a lookup method that
> > walks up the package structure:
> >
> > 3. check A.B.E
> > 4. check A.E
> > [5. check E -- already done]
> > 6. fail
> >
> > so that the complete scheme looks like this:
> >
> > 1. check A.B.C.E
> > 2. check E
> > 3. check A.B.E
> > 4. check A.E
> > [5. check E -- already done]
> > 6. fail
> >
> > That way I could leave intra-mx-package imports untouched and
> > still have the convenience of achieving the goal of making my mx
> > subpackages work in the mx context *plus* in the top-level
> > context thus allowing a backward compatible and flexible setup
> > for mx* users.
> 
> Comment 1: You're just giving yourself headaches by allowing
> your users to install mx in anything other than the prescribed
> manner.

Actually, I'm trying to provide them a way to smoothly switch
from the old setup to the new one. This includes myself, of
course ;-). 

> Comment 2: I generally like this scheme, but think (for
> consistency and confusion-reduction) that it should go straight
> up the tree, instead of checking the root second.

That would probably break code because the search could
find some other module having the same name as a top-level
one. OTOH, perhaps that situation is not all the common to
fear too much about it.

Walking up all the way would certainly be easier to explain to
a 12-year old ;-)

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