[Python-Dev] New Import Hook & New Zip Importer

[Moore, Paul]

On Thu,  5 Dec 2002 02:00:23 +0100, in  you wrote:

>Phew, it works.
>
>The attached tgz file contains:
>    zipper.patch: patches setup.py, Python/import.c, Python/importdl.h
>    zipimport.c: zipimport module, move to Modules/
>
>Do I need to mention it's a rough patch <wink>?

How do I build on Windows? I don't know what's needed to build the
zipimport module... (Sorry, I'm not being awkward here, I have no
idea how to set up the necessary Visual Studio stuff so that I can
build it - and someone will need to, before the patch is complete).

>import.c changes:
>    - Allow arbitrary objects on sys.path.

I still have reservations about this. Code will break... (if you
mean "string subclasses", then I feel slightly better about it)

>    - If a path entry ends in ".zip", replace that entry with
>      a zipimporter instance. (obviously, the zipimport module
>      must be available for this to work.)

This seems like a gross hack. How do I write a similar hook for
strings ending in ".tar"? This isn't a YAGNI, it's a design
constraint which I don't believe is reasonable.

>    - The search algo is:
>        [handle builtin modules and frozen]
>        for p on sys.path:
>            if hasattr(p, "find_module"):
>                handler =3D p.find_module(name)
>                if handler is None:
>                    continue
>            if isinstance(p, str):
>                [do builtin import]

Who handles checking for pyc/pyo, looking at timestamps,
saving compiled source (if possible) etc?

Note that Jim Ahlstrom's patch modified the search order
so that *both* of pyc and pyo were considered. (This is to
allow python -O runs to get compiled modules from a zipfile
when only .pyc were available in the zipfile. There was a
discussion at the time about why this was good - I can't
recall the details just now). Your hooks don't seem to
support modified search orders like this.

>import.c todo/notes:
>    - clean up, refactor, debug, document

Too right! I don't see any benefits in terms of code
readability for this patch (compared to Jim's code). In
both cases, import.c is still pretty incomprehensible :-)

That's about all the comments I can make, without building
the code and trying it out.

As a point of reference, could you possibly try the benchmark
code I sent you? If for no other reason than to see if it
runs under your patch...

Paul.