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

Greg Stein gstein@lyra.org
Sat, 19 Feb 2000 05:26:00 -0800 (PST)


On Wed, 16 Feb 2000, Guido van Rossum wrote:
>...
> > I've been thinking of something along the lines of
> > _determine_import_context() returning a list of things to try. Default is
> > to return something like [current-context,] + sys.path (not exactly that,
> > but you get the idea). The _import_hook would then operate as a simple
> > scan over that list of places to attempt an import from. MAL could
> > override _determine_import_context() to return the walk-me-up, intervening
> > packages. Tim could just always return sys.path (and never bother trying
> > to determine the current context).
> 
> 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.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/