[Python-Dev] Alternative Approach to Relative Imports
Mon, 27 Sep 1999 12:53:30 -0400
M.-A. Lemburg wrote:
> Currently, the imputil apporach uses a simple chaining
> technique. Unfortunately, it doesn't allow inspecting the chain
> for already loaded hooks, so the same type of hook could be
> loaded more than once.
I was hoping Greg would jump in, but since he hasn't -
You're associating the hook with the strategy. That's the old
style. The imputil style is to associate the hook with the
actual stuff being managed. The strategy is a property of the
> Also, there are at least two types of hooks:
> 1. hooks that redirect the import to some other data source
> 2. hooks that modify the way modules are searched
> Since the first variant may well also be suited to used by the
> second, the simple chaining method probably won't be powerful
> enough to handle it.
The top level question is "is it mine to import?". Greg provides
a framework that makes it easy to use alternate data sources,
and alternate ways of finding things but that's not really the
key thing. You're a "good" importer if you can (when
appropriate) way "no it's not mine" efficiently.
> Another quirk that I think needs fixing:
> When I issues an import:
> import mx.DateTime
> the whole import is handled by the importer installed at
> the start of the import. It is not possible to install a
> different importer e.g. in mx/__init__.py to handle the rest of
> the import (in this case the import of subpackage DateTime). I
> think that the importer should honor the __importer__ function
> (this is set by imputil) if present to let it continue the import
> of subsequent elements in the dotted name.
Sure you can. Your first importer is the "mx" importer. It has a
dict of sub-importers. When mx/DateTime/__init__.py runs, it
puts itself into that dict. The importer chain is now a tree.
This means, I think, that a "general" relative-path importer (ie,
one that uses the default PYTHONPATH strategy), should be
careful to install itself as the penultimate importer in the chain,
(ie, the last before __builtin__.imp). But putting a relative-path
search strategy into the "mx" importer is fine if it can quickly
determine that the target is / is not a valid name in the "mx"