[Import-sig] Re: import "domain" question (was: Long-awaited imputil comments)

Guido van Rossum guido@python.org
Mon, 21 Feb 2000 13:32:39 -0500

> > Yes.  In ni (remember ni?) we had this mechanism; it was called
> > "domain" (not a great name for it).  The domain was a list of packages
> > where relative imports were sought.  A package could set its domain by
> > setting a variable __domain__.  The current policy (current package,
> > then toplevel) corresponds to a 2-item domain: [<packagename>, ""]
> > <(where "" stands for the unnamed toplevel package).
> > Walk-me-up-Scotty corresponds to a domain containing the current
> > package, its parent, its grandparent, and so on, ending with "".  The
> > "no relative imports" policy is represented [""].
> > 
> > If we let __domain__ be initialized by the importer but overridden by
> > the package, we can do everything we need.

> How is this different from __path__ ??
> Is it simply that __path__ refers to the filesystem, while __domain__
> refers to the package namespace? If so, then that seems like duplicate
> functionality. I can easily see constructing a __path__ using the __file__
> attribute and "walking up the directory tree". Certainly a bit
> nicer/faster than checking two "paths" inside the import system.

No, no, no!

If you are looking for foo.py in sys.path, the full module name will
be "foo", no matter where you find it.  If you are looking for it in
various packages, the module name will be foo *prefixed with the name
of the package where you found it*!  This doesn't affect the importer
much (since they asked for it by foo anyway), but it greatly affects
the sys.modules administration, and it affect when you have hard name

--Guido van Rossum (home page: http://www.python.org/~guido/)