As it seems I am supposed to introduce myself on my first post, I am a professional software engineer in Colorado, USA, blessed with the chance to implement my solutions in Python. I've a fairly diverse background in languages, but the most experience with C++. I keep working on the RuneBlade project <http://www.runeblade.com>, which helps me deliver my Python solutions just that much faster. Seaching for a better language, Python has satisfied my thirst, seeming to combine my best experiences from Lisp, Pascal, C++ and others. Thanks for all of your hard work! Now it's time for me to try and help! IMO, Just's approach seems to be flexable enough to solve more than the problem at hand. Not only does the framework help to implement PEP 273, allowing for import from zip files, but it provides a very logical place for other import mechanisms to be implemented. Expanding upon Tim Delaney's desires to include importing from tar files and internet references, consider being able to extend this mechanism to importing from an XML document, database of modules, bz2 files, and even encrypted collections, The key, as I see it, is the flexability of the approach. One can even add and remove import stratigies on the fly without prior knowledge of all the import hooks! :-) As for keeping the import order of the sys.path, Tim seems to have hit the mark with the default importer supporting "sub-hooks" for the different path entry types. The best part about the import_hooks approach is that it leaves enough flexability with developer to implement creative approaches, while maintaining a commonly recognized standard for import hook interfaces. Even module-caching import hooks can use this model. One could write a simple hook that would log all imports, or all imports that could not be found, regardless of others import hooks. (Well, at least, if they behave properly ;) -Shane Holloway