[Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Ethan Furman]

On 02/23/2015 11:01 AM, Daniel Holth wrote:
> On Mon, Feb 23, 2015 at 1:49 PM, Paul Moore wrote:
>> On 23 February 2015 at 18:40, Brett Cannon wrote:
>>>
>>> Couldn't you just keep it in memory as bytes and then write directly over
>>> the file? I realize that's a bit wasteful memory-wise but it is possible.
>>> The docs could mention the memory cost is something to watch out for when
>>> doing an in-place replacement. Heck the code could even make it an
>>> io.BytesIO instance so the rest of the code doesn't have to care about this
>>> special case.
>>
>> I did consider this option, and I still quite like it. In fact,
>> originally I wrote the API to *only* be in-place, until I realised
>> that wouldn't work for things bigger than memory (but who has a Python
>> app that's bigger than RAM?)
>>
>> I'm happy to modify the API along these lines (details to be thrashed
>> out) if people think it's worthwhile.
>
> Sounds reasonable. It could be done by just reading the entire file
> contents after the shebang and re-writing them with the necessary
> offset all in RAM, truncating the file if necessary, without involving
> the zipfile module very much; the shebang could have some amount of
> padding by default; the file could just be re-compressed in memory
> depending on your appetite for complexity.

This could be a completely stupid question, but how does the zip file know where the individual files are?  More to the
point, does the index work via relative or absolute offset?  If absolute, wouldn't the index have to be rewritten if the
zip portion of the file moves?

--
~Ethan~

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150223/97c98190/attachment.sig>