[Python-checkins] r52290 - sandbox/trunk/import_in_py/importer.py

[Jim Jewett]

On 10/11/06, brett.cannon <python-checkins at python.org> wrote:
> New Revision: 52290

> Modified:
>    sandbox/trunk/import_in_py/importer.py
> Log:
> Add a note of what changes would be needed for zipimport to be easily
> implemented in Python along with reuse of the source and bytecode handlers.

> +XXX zipimport use-case:
> +    * New path_hooks function.
> +        + If sys.path entry is an existing zip file, return an importer for it.
> +        + Initialize the path_hooks function with handlers that are to be considered
> +          for use.
> +    * New importer.
> +        + Open zipfile and check if it has a path to the desired module.
> +    * New loader.
> +        + Return a new file-like object for the zipfile for the contained file.
> +            - Implement read().
> +                * Should it implement # of bytes to return, or just a complete read?
> +            - Have a 'name' attribute.

I'm not quite sure I understand your intent.  I thought the algorithm
was basically

    for location in sys.meta_path:
        loader = location.find_module(fullname, path, level)
        if loader:
            return loader.load_module(fullname)
    else:
        raise ImportError("Could not find %s" % fullname)

where a typical storage would try delegating to each format_handler
(such as source, bytecode, PTL) in turn.

Then the only thing special about a ZipImporter is that it would use a
zipfile for (raw data) storage instead of a generic filesystem
directory.

But your XXX comment makes it look like zipimport is a special kind of
file, rather than a special kind of directory.

-jJ