I'm the maintainer of Python's runpy module, and one of the maintainers of the current import system. While our import system is impressively flexible, I'd advise against adopting it wholesale without making a few tweaks - due to backwards compatibility concerns, there are bunch of things that are more awkward than they would otherwise need to be.

One thing that hurt with PEP 302 in Python is how long it took us to convert the core import system over to using it. For the better part of a decade, anyone doing anything complex with import hooks has been stuck implementing two pieces: one handling PEP 302 compliant loaders (such as zip imports), and a second handling the standard filesystem based import mechanism. It's only in the forthcoming 3.3 that handling PEP 302 loaders will also take care of handling modules imported through the standard filesystem import mechanism. Try not to repeat that mistake if you can possibly avoid it.

PEP 420 (implemented for Python 3.3) makes some additions to the protocol to allow importers to contribute portions to namespace packages. It also fixes a naming problem in the Finder API definition (effectively replacing the misnamed "find_module" with the more accurate "find_loader"). This should hopefully all be documented more clearly in the language spec by the time 3.3rc1 rolls around in a couple of weeks time.

Another notable problem is that the approach documented specifically in PEP 302 has way too much process global state. Don't follow us down that path - try to encapsulate the state in a more coherent object model so it's slightly easier to selectively import other modules (C extension modules are the bane of making any such encapsulation completely effective, but even some level of encapsulation can be helpful).

PEP 406 (http://www.python.org/dev/peps/pep-0406/) discusses a possible backwards compatible evolution of Python's approach with improved state encapsulation. If you have an encapsulated state model from the beginning though, then you can define your APIs accordingly and avoid having importers and loaders access global state at all (instead being passed a reference to the active engine).

Another missing piece in PEP 302 is the ability to ask an importer for an iterator over the modules provided by that importer (this is necessary for things like freeze utilities and automatic documentation utilities that extract docstrings). Since it's incredibly useful, you'd probably be better off standardising it from the get go: http://docs.python.org/dev/library/pkgutil#pkgutil.iter_modules (we'll probably finally elevate this to a formally specified API in Python 3.4)

And my last comment is that you should take a close look at the division of responsibility between the import system and the loader objects. In particular, consider splitting the "load_module" API into separate "init_module" and "exec_module" steps. That should allow you to minimise the degree to which loaders need to interact directly with the import state.

PEP 302 and importlib are a great starting point for a more flexible import system, but there are definitely mistakes we made that are worth avoiding.