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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4