[Python-Dev] Alternative Approach to Relative Imports

[Gordon McMillan]

M.-A. Lemburg wrote:
[msg 1]
> 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 
hook.

> 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.
[msg 2]
> 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" 
namespace.

- Gordon