On Mon, 1 Feb 1999, Just van Rossum wrote:
Greg Stein wrote:
get_code() is *NOT* a public method. It is for subclasses to override.
Oh, ok. But that makes it very specific to your implementation. I'd like to see a much more general idea. I'm sure that it's there in your code but it is not very clear...
My post was only about implementation, as an expression of an implicit design :-) And yes, it appears that the doc could be clearer.
The "public method" is the _import_hook method, but it isn't really public, as it gets installed into the import hook. However, it wouldn't be hard to add "__call__ = _import_hook" to the Importer class. That would provide the appropriate callable interface.
I see, that makes sense. Then the idea could boil down to something like this:
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). 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). Cheers, -g -- Greg Stein, http://www.lyra.org/