<br><br><div class="gmail_quote">On Sun, Aug 30, 2009 at 10:40 PM, Jeroen Ruigrok van der Werven <span dir="ltr"><<a href="mailto:asmodai@in-nomine.org" target="_blank">asmodai@in-nomine.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>-On [20090831 06:29], Collin Winter (<a href="mailto:collinw@gmail.com" target="_blank">collinw@gmail.com</a>) wrote:<br>
>Are there any applications/frameworks which have zip files on their<br>
>critical path, where this kind of (admittedly impressive) speedup<br>
>would be beneficial? What was the motivation for writing the C<br>
>version?<br>
<br>
</div>Would zipped eggs count? For example, SQLAlchemy runs in the 5 MB range.<br></blockquote><div><br></div><div>Unless someone's also pushing for being able to import and execute code from scrambled zip files, no that doesn't matter.</div>
<div><br></div><div>The C code for this should be trivially tiny. See the zipfile._ZipDecryptor class, its got ~25 lines of actual code in it. It is not worth arguing about. I'll commit this if you post it as a patch in a tracker issue. Please make sure your patch includes the following:</div>
<div><br></div><div>* A unittest that compares the C version of the descrambler to the python version of the descrambler using a variety of inputs and outputs that exercise any boundary condition.</div><div><br></div><div>
* Conditional import code in the zipfile module itself so that the module works even if the C module isn't available.</div>
<div><br></div><div>-Greg</div><div><br></div></div>