[Python-Dev] zipimport, round 3 (or would that be that 37?)

[Paul Moore]

Just van Rossum <just@letterror.com> writes:

> I'll write a bit about the mechanics tomorrow, but in the meantime I would like
> to see some test results/bug reports/bug fixes from Windows developers. Please
> don't start with the full monty (ie. the std lib), try a small test archive
> first please ;-)

The patch applies fine to my copy of Python (downloaded from CVS Dec
1st - I can't get cvs update to cooperate for me :-() with an offset
of -3 in most of the import.c changes (I assume that's just because
I'm a bit out of date).

To get zipimport as a builtin, apply the following patch, and add
zipimport.c to the pythoncore project.

--- PC\config.c.orig	Sun Jul 07 03:59:34 2002
+++ PC\config.c	Sun Dec 08 15:37:03 2002
@@ -43,6 +43,7 @@
 extern void init_weakref(void);
 extern void init_hotshot(void);
 extern void initxxsubtype(void);
+extern void initzipimport(void);
 
 /* XXX tim: what's the purpose of ADDMODULE MARKER? */
 /* -- ADDMODULE MARKER 1 -- */
@@ -96,6 +97,7 @@
 	{"_hotshot", init_hotshot},
 
 	{"xxsubtype", initxxsubtype},
+	{"zipimport", initzipimport},
 
 /* XXX tim: what's the purpose of ADDMODULE MARKER? */
 /* -- ADDMODULE MARKER 2 -- */

Zipimport doesn't work at all for me as a dynamic extension. Is this
just a temporary problem, an issue specific to the zipimport module,
or a limitation in the hook mechanism? (I assume not the last, as that
would make it pretty useless as a general mechanism...)

As a builtin, it works fine in a release build. But a debug build
asserts in fopen() as the filename is "".

An easy fix for this is to add a check in zipimporter_init(),

    if (lenpath == 0) {
        PyErr_SetString(PyExc_ImportError, "archive path is empty");
        return -1;
    }

Do we need to set an error string there? It's not really an error, as
such.

BTW, I don't see any code for checking timestamps of .pyc files
against .py files. Did you omit that (and if so, was it deliberate or
accidental)?

I hit an odd case when I was testing interactively. I set sys.path to
a list containing just 'ziptest.zip', and then tried to import a
module. Zipimport failed because zlib wasn't accessible. That's OK,
but when I reset sys.path, zipimport *still* claimed it couldn't
decompress as zlib wasn't available. I see why - the optimisation in
get_decompress_func() only checks for zlib once - but nevertheless it
is annoying that I can only "fix" my mistake by restarting the
interpreter. This is never going to happen "in real life", so it's not
crucial. But maybe reload(zipimport) could be made to retry the check?

I also tried a Python import hook. It seemed to be doing the right
things. I didn't try too hard - just dummy {find,load}_module methods,
and an __init__. It looked like errors were generated as a result of
me not implementing the protocol right, which is good :-)

Paul.

PS The code *still* looks messy. I think that's just C though - I've
   got so used to writing Python code that *any* C looks messy :-)

-- 
This signature intentionally left blank