Junto a ncoghlan, soy el otro responsable del sistema de importación de Python y el autor de su implementación actual, importlib (http://docs.python.org/dev/py3k/library/importlib.html). Estoy de acuerdo con todo lo que Nick dijo, así que solo quiero agregar información adicional.
Primero, no confíe demasiado en PEP 302 directamente, sino que observe lo que importlib proporciona en términos de clases base abstractas, etc. Para que las cosas fueran compatibles con versiones anteriores, tenía que ser compatible con PEP 302, pero tuve que agregar algunas de mis APIs propias para terminar de desarrollar el soporte para una verdadera flexibilidad.
Otro punto importante es que le está dando a los desarrolladores dos piezas de flexibilidad. Una es la capacidad de almacenar código de una manera que no sea solo directamente en el sistema de archivos como archivos individuales (lo llamo el back-end de almacenamiento para las importaciones), por ejemplo, esto permite que el código viva en un archivo zip, una base de datos sqlite, etc. El otro soporte es permitir el control del código de proceso previo o posterior de alguna manera, por ejemplo, Quijote (https://www.mems-exchange.org/software/quixote/) y su uso alternativo de literales de cadena no asignados a una variable sería mucho más fácil de soportar.
Si bien este último rara vez se necesita, el primero es donde debe preocuparse por el soporte. Y aquí es donde terminas redefiniendo prácticamente las API de interacción del sistema de archivos. Dado que algunas personas necesitan activos almacenados como archivos con su código, debe proporcionar una buena manera de leer archivos, descubrir archivos, etc. Todavía tenemos que implementar la parte de la API para descubrir qué archivos de datos están disponibles, enumerarlos, etc. .
Pero también tiene la necesidad de API que sean específicas del código. Como Nick mencionó, terminas necesitando API para descubrir qué módulos contiene un paquete, etc., que no son específicos de un archivo. Existe esta extraña dualidad de tener API para manejar módulos en los que ha extraído el concepto de archivos, pero luego termina necesitando proporcionar API para acceder a datos de activos similares a archivos. Y tan pronto como intente implementar uno en relación con el otro para evitar la duplicación, las aguas se vuelven realmente turbias (es decir, las personas terminan confiando en la estructuración esperada de la ruta del archivo, etc., sin prestar atención al hecho de que la ruta puede no ser una ruta verdadera porque es para un archivo zip que contiene código y no solo un archivo). IOW terminarás teniendo que implementar dos API similares, pero estarás mejor a largo plazo.
Como dijo Nick, nuestra solución es un buen punto de partida, pero no es así como lo haría hoy si estuviera diseñando la API desde cero.