[Import-sig] import "domain" question (was: Long-awaited imputil comments)
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.
Greg Stein, http://www.lyra.org/