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

[Just van Rossum]

Paul Moore wrote:

> Sorry. Basically it just didn't find the module in the zipfile. I
> don't think it's a big deal. If you want, I can rebuild as a dynamic
> module and try with -v.

Don't worry, I've found (and solved) the problem and am playing with a dynamic
build as we speak.

[time stamp checking]
> To be honest, I think that this is one of the nastiest hurdles to
> writing a good import hook - replicating (or even understanding the
> logic for!) the hairy extension and timestamp checking code used for
> normal imports.

Not all import hooks will need to support all of .pyc, .pyc and .py. I for one
would've been more than happy for zipimport to only support .pyc ;-)

> Refactoring and encapsulating that would potentially
> help in a lot of cases. Except that maybe it's not always exactly the
> same (you can't write a compiled .pyc file back to a zip file, you
> can't load a C extension from a zipfile, ...) But that isn't an issue
> for this patch.

Right; I need to peek in the zipfile.py module to see how the time/date shorts
from the zip archive translate to a usable timestamp. I've updated my code so it
at least doesn't throw away those values ;-)

> > Right, but maybe I simply shouldn't remember that a previous zlib
> > import failed, and just try again.
> 
> I thought of that - it slows things down when zlib isn't available, as
> it checks (and fails) every time. How bad this is, I'm not sure...

That was my original rationale, too, but it's wrong: it only checks if
compression is *needed* and *if* zlib is not available then, the program will
abort with a traceback anyway... I've changed it in my local copy.

[ ... ]
> But you let me write import hooks in Python and avoid C, so you're my
> friend for life :-)

Heh. Make sure to buy me a beer some time -- and I'll be sure to buy you one
right back ;-)

Just