<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 23, 2015 at 8:22 PM, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/23/2015 11:01 AM, Daniel Holth wrote:<br>
<span class="">> On Mon, Feb 23, 2015 at 1:49 PM, Paul Moore wrote:<br>
>> On 23 February 2015 at 18:40, Brett Cannon wrote:<br>
>>><br>
>>> Couldn't you just keep it in memory as bytes and then write directly over<br>
>>> the file? I realize that's a bit wasteful memory-wise but it is possible.<br>
>>> The docs could mention the memory cost is something to watch out for when<br>
>>> doing an in-place replacement. Heck the code could even make it an<br>
>>> io.BytesIO instance so the rest of the code doesn't have to care about this<br>
>>> special case.<br>
>><br>
>> I did consider this option, and I still quite like it. In fact,<br>
>> originally I wrote the API to *only* be in-place, until I realised<br>
>> that wouldn't work for things bigger than memory (but who has a Python<br>
>> app that's bigger than RAM?)<br>
>><br>
>> I'm happy to modify the API along these lines (details to be thrashed<br>
>> out) if people think it's worthwhile.<br>
><br>
</span><span class="">> Sounds reasonable. It could be done by just reading the entire file<br>
> contents after the shebang and re-writing them with the necessary<br>
> offset all in RAM, truncating the file if necessary, without involving<br>
> the zipfile module very much; the shebang could have some amount of<br>
> padding by default; the file could just be re-compressed in memory<br>
> depending on your appetite for complexity.<br>
<br>
</span>This could be a completely stupid question, but how does the zip file know where the individual files are?  More to the<br>
point, does the index work via relative or absolute offset?  If absolute, wouldn't the index have to be rewritten if the<br>
zip portion of the file moves?<br></blockquote><div><br></div><div>Yes and no. The ZIP format uses a 'central directory' which is a record of each file in the archive. The offsets are relative (although the specification is a little vague on what they're relative *to* when using a .zip file. The wording talks about disk numbers, ZIP being from the era of floppy disks.) You find the central directory by searching from the end (or reading a specific spot at the end, if you don't support archive comments. zipimport, for example, doesn't support archive comments) and it turns out you can find the central directory from just that information (and as far as I know, all tools do.) However, there are still some offsets that would change if you add stuff to the front of the ZIP file (or remove it), and some zip tools will complain (usually just in verbose mode, though.)</div></div><div><br></div>-- <br><div class="gmail_signature">Thomas Wouters <<a href="mailto:thomas@python.org" target="_blank">thomas@python.org</a>><br><br>Hi! I'm an email virus! Think twice before sending your email to help me spread!</div>
</div></div>