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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4