Happy New Year! I've attached a new imputil.py to this message. It isn't posted on my page yet, as I'd like some feedback before declaring this new version viable. In this imputil, there is an ImportManager class. It gets installed as the import hook, with the presumption that it is the only import hook (technically, it could chain, but I've disabled that for now). I think Python 1.6 should drop the __import__ builtin and move to something like sys.import_hook (to allow examination and change). Another alternative would be sys.get_import_hook() and sys.set_import_hook(). [ I don't think we would want a "set" that returned the old version as the only way to get the current hook function; we want to be able to easily find the ImportManager instance. ] The ImportManager knows how to scan sys.path when it needs to find a top-level module/package (e.g. given a.b.c, the "a" is the top-level; b.c falls "below" that). sys.path can contain strings which specify a filesystem directory, or it can contain Importer instances. The manager also records an ordered list of suffix/importer pairs. The add_suffix() method is used to append new suffixes, but clients can also access the .suffixes attribute for fine-grained manipulation/ordering. There is a new importer called _FilesystemImporter which understands how to look into a directory for Python modules. It borrows/refers to the ImportManager's .suffixes attribute, using that to find modules in a directory. This is also the Importer that gets associated with each filesystem-based module. The importers used for suffix-based importing are derived from SuffixImporter. While a function could be used here, future changes will be easier if we presume class instances. The new imputil works fine (use _test_revamp() to switch to the new import mechanism). Importer subclasses using the old imputil should continue to work, although I am deprecating the 2-tuple return value for get_code(). get_code() should return None or the 3-tuple form now. I think I still have a bit more work to do, to enable something like "import a.b.c" where a.zip is an archive on the path and "b.c" resides in the archive. Note: it *is* possible to do sys.path.append(ZipImporter(filename)) and have "a.b.c" in the Zip file. It would simply be nicer to be able to drop arbitrary .zip files onto the path and use their basename as the top-level name of a package. Anyhow: I haven't looked at this scenario yet to find what the new system is missing (if anything). As always: feedback is more than appreciated! Especially from people using imputil today. Did I break anything? Does the new scheme still feel right to you? etc. Cheers, -g p.s. I'd also like to remove PackageArchiveImporter and PackageArchive. They don't seem to add any real value. I might move DirectoryImporter and PathImporter to an "examples" file, too. -- Greg Stein, http://www.lyra.org/