Next to ncoghlan I'm the other maintainer of Python's import system and the author of its current implementation, importlib (http://docs.python.org/dev/py3k/library/importlib.html). Everything Nick said I agree with, so I just want to add some extra info.
First, don't rely too heavily on PEP 302 directly but instead look at what importlib provides in terms of abstract base classes, etc. For backwards-compatibility things had to be be compatible with PEP 302, but I had to add some of my own APIs in order to finish fleshing out the support for true flexibility.
Another important point is that you are giving developers two pieces of flexibility. One is the ability to store code in a way other than just directly on the file system as individual files (I call this the storage back-end for imports), e.g. this is allowing code to live in a zip file, sqlite database, etc. The other support is in allowing control to pre- or post-process code in some way, e.g. Quixote (https://www.mems-exchange.org/software/quixote/) and its alternative use of string literals not assigned to a variable would be much easier to support.
While the latter is rarely needed, the former is where you have to worry about support. And this is where you end up practically redefining file system interaction APIs. Since some people need assets stored as files with their code, you need to provide a good way to read files, discover files, etc. We still need to implement the part of the API for discovering what data files are available, listing them, etc.
But then you also have the need for APIs which are code-specific. As Nick mentioned, you end up needing APIs on discovering what modules a package contains, etc. which are not file-specific. There is this odd duality of having APIs for dealing with modules where you have extracted away the concept of files, but then you end up needing to provide APIs to access file-like asset data. And as soon as you try to implement one in regards of the other to avoid duplication the waters get really murky (i.e. people end up relying on expected file path structuring, etc. without paying attention to the fact the path may not be a true path because it is for a zipfile containing code and not just a file). IOW you will end up having to implement two similar APIs, but you will be better off for it in the long run.
As Nick said, our solution is a good starting point, but it isn't how I would do it today if I was designing the API from scratch.