At 5:41 AM -0800 2/1/99, Greg Stein wrote:
Each element of sys.path is either of these: - a string, in which case the "classic" importer will do the work. - a callable object, which must have the same interface (signature) as the current __import__ hook.
(that's basically where you started, right?)
Exactly.
And within that design, my implementation also favors a single-step import mechanism rather than the find/load style that has characterized previous import mechanisms (imp, ihooks, Mark/Jack's email, etc).
What I really like about your idea (not your implementation ;-) is that it doesn't replace the __import__ hook, but it expands the semantics of sys.path so it can contain _additional_ hooks. Which is what most people need in the first place. It saves you the trouble to emulate the whole import process (which as you know is almost impossible to do 100% right...). So instead of writing ugly and error-prone replacements for __import__, you just write a specialized loader and whack it into sys.path. Very cool.
The import design is also compatible with existing code. Only when somebody begins to insert callable objects will old apps potentially break. IMO, they can choose to not use callable objects and leave their app alone, or use callables and fix their app to compensate.
Mainly, I'm just hoping that my code is useful to demonstrate viability of the approach that I'm recommending. "Code talks" :-) I've certainly found the Importer class to be a clearer way to write custom import hooks than anything else that I've seen (try writing a subclass of the ihooks classes, and you'll see what I mean).
Yes: been there, done that ;-) Just